Je suis développeur Java principalement (bouuuh, bouuuh, ...), et C++
occasionnel.
J'ai eu l'occasion de discuter ici ou ailleurs avec certains habitués
(Fabien, Kame, Christophe de mémoire). On avait notamment discuté des
avantages/inconvénients respectifs de Java et C++... A cette ocasion
j'avais découvert des alternatives propres à certaines pratiques que
je considère comme douteuses dans l'usage du C++ que je connais
(C/C++, principalement sous VC++).
Actuellement je suis ammené à faire de + en + de C/C++ ce qui
m'emmerde profondément. ça n'est pas que je n'aime pas C++, mais
fesant pas mal de Java, je ne supporte pas les absurdités de la
programmation C/C++ sous Windows. Pourquoi éxiste-t-il 873
redéfinition d'un entier 32 bit??? Les programmeur de chez MS sont
payés au #define? Pourquoi dans VC++ on doit choisir entre CString qui
est non portable, et "char *" qui est légèrement primitif!!! (J'ai
une idée de la réponse...). On devrait disposer avec chaque
environnement C++ d'un bibliothèque portable reprenant au minimum les
fonctions des packages java.lang et java.util de java...
Il me semble qu'il y a un fossé (20 ans et pas mal de bon sens) entre
ce que je lis ici et ce que je constate dans la "vraie vie" (du moins,
la mienne)!!! Que me conseilleriez-vous pour me sortir de cette
panade?
Comment faire du C++ propre et portable (GUI portable en option) en
alternative à VC++. Ou, comment et avec quoi bossez-vous? Quel IDE,
quel compilo et surtout quelle(s) bibliothèque(s) pour remplacer les
MFC? Le tout à l'echelle d'une PME et sans obliger tous mes collègues
à migrer avec moi (même si certains me suivraient bien volontier). Je
sais, je suis très éxigeant, mais bon, je viens de java ;-)
Au passage, je suis bien intéressé par des bons livres (de préférence
en français, mais pas obligatoirement) sur la bonne programmation
(C/)C++... Mais j'imagine qu'en faisant qq recherches je trouverais la
réponse dans les archives... (si vous avez un lien vers un post
intressant...)
Remettre le mot LGPL dans le contexte. Elle etait comparée a la GPL. Et la LGPL est plus permissive que la GPL (on peut garder le code qui utilise wxWidgets secret, chose impossible avec la GPL)
Pour être plus précis, tu peux garder le code qui utilise une bibliothèque GPL secret, mais il faut aussi que tu garde le binaire secret ... (si tu distribue le binaire, tu dois donner accès aux sources)
Remettre le mot LGPL dans le contexte. Elle etait comparée a la GPL.
Et la LGPL est plus permissive que la GPL (on peut garder le code qui
utilise wxWidgets secret, chose impossible avec la GPL)
Pour être plus précis, tu peux garder le code qui utilise une
bibliothèque GPL secret, mais il faut aussi que tu garde le binaire
secret ... (si tu distribue le binaire, tu dois donner accès aux
sources)
Remettre le mot LGPL dans le contexte. Elle etait comparée a la GPL. Et la LGPL est plus permissive que la GPL (on peut garder le code qui utilise wxWidgets secret, chose impossible avec la GPL)
Pour être plus précis, tu peux garder le code qui utilise une bibliothèque GPL secret, mais il faut aussi que tu garde le binaire secret ... (si tu distribue le binaire, tu dois donner accès aux sources)
-- Matthieu
Matthieu Moy
Fabien LE LEZ writes:
soit libre, soit commercial.
Attention aux abus de langage : Un logiciel peut être libre et commercial à la fois (la RedHat Enterprise Linux est on ne peut plus commerciale, et pourtant n'utilise que des logiciels libres).
Le contraire de libre, c'est propriétaire.
Bon, je pinaille là, mais c'est important ;-)
-- Matthieu
Fabien LE LEZ <gramster@gramster.com> writes:
soit libre, soit commercial.
Attention aux abus de langage : Un logiciel peut être libre et
commercial à la fois (la RedHat Enterprise Linux est on ne peut plus
commerciale, et pourtant n'utilise que des logiciels libres).
Attention aux abus de langage : Un logiciel peut être libre et commercial à la fois (la RedHat Enterprise Linux est on ne peut plus commerciale, et pourtant n'utilise que des logiciels libres).
Le contraire de libre, c'est propriétaire.
Bon, je pinaille là, mais c'est important ;-)
-- Matthieu
drkm
Matthieu Moy writes:
Gabriel Dos Reis writes:
C'est un non-argument : si tu veux faire un binding, certainement, tu ne veux pas utiliser les fonctionnalités avancées dans _l'interface_ mais rien ne t'empêche de les utiliser dans l'implémentation.
Bien sur, mais c'est vrai que ce n'est pas très pratique d'utiliser une partie différente du langage dans l'interface et dans l'implémentation. Possible, mais pas très pratique.
Pourquoi ? Si tu veux fournir des listes de machins, trucs et bidules, je trouverais très pratique d'utiliser des modèles dans l'implémentation, même si le langage cible du binding ne supporte pas ce concept. Si la puissance du langage cible est limité à cet égard, ça ne change rien à l'implémentation qui elle, reste en C++.
Non ?
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
C'est un non-argument : si tu veux faire un binding, certainement, tu
ne veux pas utiliser les fonctionnalités avancées dans _l'interface_
mais rien ne t'empêche de les utiliser dans l'implémentation.
Bien sur, mais c'est vrai que ce n'est pas très pratique d'utiliser
une partie différente du langage dans l'interface et dans
l'implémentation. Possible, mais pas très pratique.
Pourquoi ? Si tu veux fournir des listes de machins, trucs et
bidules, je trouverais très pratique d'utiliser des modèles dans
l'implémentation, même si le langage cible du binding ne supporte pas
ce concept. Si la puissance du langage cible est limité à cet égard,
ça ne change rien à l'implémentation qui elle, reste en C++.
Non ?
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
C'est un non-argument : si tu veux faire un binding, certainement, tu ne veux pas utiliser les fonctionnalités avancées dans _l'interface_ mais rien ne t'empêche de les utiliser dans l'implémentation.
Bien sur, mais c'est vrai que ce n'est pas très pratique d'utiliser une partie différente du langage dans l'interface et dans l'implémentation. Possible, mais pas très pratique.
Pourquoi ? Si tu veux fournir des listes de machins, trucs et bidules, je trouverais très pratique d'utiliser des modèles dans l'implémentation, même si le langage cible du binding ne supporte pas ce concept. Si la puissance du langage cible est limité à cet égard, ça ne change rien à l'implémentation qui elle, reste en C++.
Non ?
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
Gabriel Dos Reis
Matthieu Moy writes:
| Gabriel Dos Reis writes: | | > C'est un non-argument : si tu veux faire un binding, certainement, tu | > ne veux pas utiliser les fonctionnalités avancées dans _l'interface_ | > mais rien ne t'empêche de les utiliser dans l'implémentation. | | Bien sur, mais c'est vrai que ce n'est pas très pratique d'utiliser | une partie différente du langage dans l'interface et dans | l'implémentation.
Quelle partie différente ? De quoi parles-tu ?
| Possible, mais pas très pratique.
Huh ? Je fais ça (extern "X") tous les jours et c'est très partique.
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| > C'est un non-argument : si tu veux faire un binding, certainement, tu
| > ne veux pas utiliser les fonctionnalités avancées dans _l'interface_
| > mais rien ne t'empêche de les utiliser dans l'implémentation.
|
| Bien sur, mais c'est vrai que ce n'est pas très pratique d'utiliser
| une partie différente du langage dans l'interface et dans
| l'implémentation.
Quelle partie différente ? De quoi parles-tu ?
| Possible, mais pas très pratique.
Huh ? Je fais ça (extern "X") tous les jours et c'est très partique.
| Gabriel Dos Reis writes: | | > C'est un non-argument : si tu veux faire un binding, certainement, tu | > ne veux pas utiliser les fonctionnalités avancées dans _l'interface_ | > mais rien ne t'empêche de les utiliser dans l'implémentation. | | Bien sur, mais c'est vrai que ce n'est pas très pratique d'utiliser | une partie différente du langage dans l'interface et dans | l'implémentation.
Quelle partie différente ? De quoi parles-tu ?
| Possible, mais pas très pratique.
Huh ? Je fais ça (extern "X") tous les jours et c'est très partique.
-- Gaby
drkm
Matthieu Moy writes:
Martinez Jerome writes:
Remettre le mot LGPL dans le contexte. Elle etait comparée a la GPL. Et la LGPL est plus permissive que la GPL (on peut garder le code qui utilise wxWidgets secret, chose impossible avec la GPL)
Pour être plus précis, tu peux garder le code qui utilise une bibliothèque GPL secret, mais il faut aussi que tu garde le binaire secret ... (si tu distribue le binaire, tu dois donner accès aux sources)
Les sources qui utilisent la bibliothèque ? Tiens, je pensais que ce n'était pas le cas.
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
Remettre le mot LGPL dans le contexte. Elle etait comparée a la GPL.
Et la LGPL est plus permissive que la GPL (on peut garder le code qui
utilise wxWidgets secret, chose impossible avec la GPL)
Pour être plus précis, tu peux garder le code qui utilise une
bibliothèque GPL secret, mais il faut aussi que tu garde le binaire
secret ... (si tu distribue le binaire, tu dois donner accès aux
sources)
Les sources qui utilisent la bibliothèque ? Tiens, je pensais que
ce n'était pas le cas.
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
Remettre le mot LGPL dans le contexte. Elle etait comparée a la GPL. Et la LGPL est plus permissive que la GPL (on peut garder le code qui utilise wxWidgets secret, chose impossible avec la GPL)
Pour être plus précis, tu peux garder le code qui utilise une bibliothèque GPL secret, mais il faut aussi que tu garde le binaire secret ... (si tu distribue le binaire, tu dois donner accès aux sources)
Les sources qui utilisent la bibliothèque ? Tiens, je pensais que ce n'était pas le cas.
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
Fabien LE LEZ
On Tue, 27 Jul 2004 21:36:57 +0200, Matthieu Moy :
Bien sur, mais c'est vrai que ce n'est pas très pratique d'utiliser une partie différente du langage dans l'interface et dans l'implémentation.
Il me paraît plus facile d'utiliser du C++ dans l'implémentation, que de s'en passer et faire tout à la main (en C).
-- ;-)
On Tue, 27 Jul 2004 21:36:57 +0200, Matthieu Moy
<MatthieuNOSPAM.Moy@imag.fr.invalid>:
Bien sur, mais c'est vrai que ce n'est pas très pratique d'utiliser
une partie différente du langage dans l'interface et dans
l'implémentation.
Il me paraît plus facile d'utiliser du C++ dans l'implémentation, que
de s'en passer et faire tout à la main (en C).
On Tue, 27 Jul 2004 21:44:47 +0200, Matthieu Moy :
Le contraire de libre, c'est propriétaire.
Quel est le statut de MPEG dans cette nomenclature ?
-- ;-)
Fabien LE LEZ
On Tue, 27 Jul 2004 21:54:31 +0200, drkm :
Les sources qui utilisent la bibliothèque ? Tiens, je pensais que ce n'était pas le cas.
Si j'ai bien compris, la GPL est contagieuse : si tu utilises un bout de code en GPL quelque part dans un projet, tout le projet devient GPL. Du coup, il y a le monde des logiciels GPL, et le monde des logiciels non-GPL, et peu de ponts entre eux.
-- ;-)
On Tue, 27 Jul 2004 21:54:31 +0200, drkm <usenet.fclcxx@fgeorges.org>:
Les sources qui utilisent la bibliothèque ? Tiens, je pensais que
ce n'était pas le cas.
Si j'ai bien compris, la GPL est contagieuse : si tu utilises un bout
de code en GPL quelque part dans un projet, tout le projet devient
GPL. Du coup, il y a le monde des logiciels GPL, et le monde des
logiciels non-GPL, et peu de ponts entre eux.
Les sources qui utilisent la bibliothèque ? Tiens, je pensais que ce n'était pas le cas.
Si j'ai bien compris, la GPL est contagieuse : si tu utilises un bout de code en GPL quelque part dans un projet, tout le projet devient GPL. Du coup, il y a le monde des logiciels GPL, et le monde des logiciels non-GPL, et peu de ponts entre eux.
-- ;-)
Matthieu Moy
Gabriel Dos Reis writes:
| Bien sur, mais c'est vrai que ce n'est pas très pratique d'utiliser | une partie différente du langage dans l'interface et dans | l'implémentation.
Quelle partie différente ? De quoi parles-tu ?
Si on peut parler de "partie" d'un language, bien sur. Disons que ce que tu propose (et pratique visiblement), c'est de te limiter à un sous ensemble du C++ (le C) au niveau de l'interface. Si on considère que "sous-ensemble" et "partie" sont synonymes, je pense que tu peux comprendre de quoi je parle ;-)
| Possible, mais pas très pratique.
Huh ? Je fais ça (extern "X") tous les jours et c'est très partique.
Bon, là, on rentre dans du subjectif, je ne me lancerai pas dans une argumentation ;-) Disons que perso, si je commence à coder avec des classes et des templates, il faut s'attendre à ce que je râle au moment ou il faudra écrire un .h qui n'en utilise pas.
Le mec qui code en C pur ne se pose pas ce genre de questions existentielles.
Enfin, tout ceci étant dit, je pense (comme toi ?) qu'il y a pas mal de programmeurs en C pur qui pourraient s'offrire le luxe d'un vector<> ou d'une string<> de temps en temps, ça ne ferait pas de mal ;-)
-- Matthieu
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| Bien sur, mais c'est vrai que ce n'est pas très pratique d'utiliser
| une partie différente du langage dans l'interface et dans
| l'implémentation.
Quelle partie différente ? De quoi parles-tu ?
Si on peut parler de "partie" d'un language, bien sur. Disons que ce
que tu propose (et pratique visiblement), c'est de te limiter à un
sous ensemble du C++ (le C) au niveau de l'interface. Si on considère
que "sous-ensemble" et "partie" sont synonymes, je pense que tu peux
comprendre de quoi je parle ;-)
| Possible, mais pas très pratique.
Huh ? Je fais ça (extern "X") tous les jours et c'est très partique.
Bon, là, on rentre dans du subjectif, je ne me lancerai pas dans une
argumentation ;-) Disons que perso, si je commence à coder avec des
classes et des templates, il faut s'attendre à ce que je râle au
moment ou il faudra écrire un .h qui n'en utilise pas.
Le mec qui code en C pur ne se pose pas ce genre de questions
existentielles.
Enfin, tout ceci étant dit, je pense (comme toi ?) qu'il y a pas mal
de programmeurs en C pur qui pourraient s'offrire le luxe d'un
vector<> ou d'une string<> de temps en temps, ça ne ferait pas de
mal ;-)
| Bien sur, mais c'est vrai que ce n'est pas très pratique d'utiliser | une partie différente du langage dans l'interface et dans | l'implémentation.
Quelle partie différente ? De quoi parles-tu ?
Si on peut parler de "partie" d'un language, bien sur. Disons que ce que tu propose (et pratique visiblement), c'est de te limiter à un sous ensemble du C++ (le C) au niveau de l'interface. Si on considère que "sous-ensemble" et "partie" sont synonymes, je pense que tu peux comprendre de quoi je parle ;-)
| Possible, mais pas très pratique.
Huh ? Je fais ça (extern "X") tous les jours et c'est très partique.
Bon, là, on rentre dans du subjectif, je ne me lancerai pas dans une argumentation ;-) Disons que perso, si je commence à coder avec des classes et des templates, il faut s'attendre à ce que je râle au moment ou il faudra écrire un .h qui n'en utilise pas.
Le mec qui code en C pur ne se pose pas ce genre de questions existentielles.
Enfin, tout ceci étant dit, je pense (comme toi ?) qu'il y a pas mal de programmeurs en C pur qui pourraient s'offrire le luxe d'un vector<> ou d'une string<> de temps en temps, ça ne ferait pas de mal ;-)
-- Matthieu
drkm
Fabien LE LEZ writes:
On Tue, 27 Jul 2004 21:54:31 +0200, drkm :
Les sources qui utilisent la bibliothèque ? Tiens, je pensais que ce n'était pas le cas.
Si j'ai bien compris, la GPL est contagieuse : si tu utilises un bout de code en GPL quelque part dans un projet, tout le projet devient GPL. Du coup, il y a le monde des logiciels GPL, et le monde des logiciels non-GPL, et peu de ponts entre eux.
Oops. La discussion tournait en partie autour de la *L*GPL. J'ai loupé une lettre. Désolé.
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
Fabien LE LEZ <gramster@gramster.com> writes:
On Tue, 27 Jul 2004 21:54:31 +0200, drkm <usenet.fclcxx@fgeorges.org>:
Les sources qui utilisent la bibliothèque ? Tiens, je pensais que
ce n'était pas le cas.
Si j'ai bien compris, la GPL est contagieuse : si tu utilises un bout
de code en GPL quelque part dans un projet, tout le projet devient
GPL. Du coup, il y a le monde des logiciels GPL, et le monde des
logiciels non-GPL, et peu de ponts entre eux.
Oops. La discussion tournait en partie autour de la *L*GPL. J'ai
loupé une lettre. Désolé.
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
Les sources qui utilisent la bibliothèque ? Tiens, je pensais que ce n'était pas le cas.
Si j'ai bien compris, la GPL est contagieuse : si tu utilises un bout de code en GPL quelque part dans un projet, tout le projet devient GPL. Du coup, il y a le monde des logiciels GPL, et le monde des logiciels non-GPL, et peu de ponts entre eux.
Oops. La discussion tournait en partie autour de la *L*GPL. J'ai loupé une lettre. Désolé.
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
