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...)
| Fabien LE LEZ writes: | | > On Wed, 21 Jul 2004 10:52:40 +0200, "Mickael Pointier" | > : | > | >>Ne prend pas ton cas pour une généralité: Il n'y a pas que le "gratuit" et | >>le "libre" dans la vie. | > | > Certes. Mais ton argument n'explique pas pour autant pourquoi tant de | > bibliothèques open-source sont écrites en C. | | Parce que c'est le plus réutilisable, principalement : D'une | bibliothèque écrite en C, tu peux faire des bindings vers d'autres | langages sans trop de problèmes.
La même chose est possible en C++ -- jamais entendu parler de spécification de linkage/langage (chose que tu n'as pas en C) ?
| Avec une API en C++ plein de | templates, d'héritage, ... tu es bien embêté quand tu veux appeler ta | bibliothèque depuis un language qui n'a pas toutes ces fonctionalités.
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. Et même si c'était utilisé dans la partie interface, rien n'empêche de mettre le « extern "X" » autour du wrapper idione.
| Fabien LE LEZ <gramster@gramster.com> writes:
|
| > On Wed, 21 Jul 2004 10:52:40 +0200, "Mickael Pointier"
| > <mpointier@edengames.moc>:
| >
| >>Ne prend pas ton cas pour une généralité: Il n'y a pas que le "gratuit" et
| >>le "libre" dans la vie.
| >
| > Certes. Mais ton argument n'explique pas pour autant pourquoi tant de
| > bibliothèques open-source sont écrites en C.
|
| Parce que c'est le plus réutilisable, principalement : D'une
| bibliothèque écrite en C, tu peux faire des bindings vers d'autres
| langages sans trop de problèmes.
La même chose est possible en C++ -- jamais entendu parler de
spécification de linkage/langage (chose que tu n'as pas en C) ?
| Avec une API en C++ plein de
| templates, d'héritage, ... tu es bien embêté quand tu veux appeler ta
| bibliothèque depuis un language qui n'a pas toutes ces fonctionalités.
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.
Et même si c'était utilisé dans la partie interface, rien n'empêche de
mettre le « extern "X" » autour du wrapper idione.
| Fabien LE LEZ writes: | | > On Wed, 21 Jul 2004 10:52:40 +0200, "Mickael Pointier" | > : | > | >>Ne prend pas ton cas pour une généralité: Il n'y a pas que le "gratuit" et | >>le "libre" dans la vie. | > | > Certes. Mais ton argument n'explique pas pour autant pourquoi tant de | > bibliothèques open-source sont écrites en C. | | Parce que c'est le plus réutilisable, principalement : D'une | bibliothèque écrite en C, tu peux faire des bindings vers d'autres | langages sans trop de problèmes.
La même chose est possible en C++ -- jamais entendu parler de spécification de linkage/langage (chose que tu n'as pas en C) ?
| Avec une API en C++ plein de | templates, d'héritage, ... tu es bien embêté quand tu veux appeler ta | bibliothèque depuis un language qui n'a pas toutes ces fonctionalités.
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. Et même si c'était utilisé dans la partie interface, rien n'empêche de mettre le « extern "X" » autour du wrapper idione.
-- Gaby
Fabien LE LEZ
On 25 Jul 2004 11:55:37 +0200, Gabriel Dos Reis :
la réticence à utiliser C++ est lié au moins à deux facteurs : (1) ignorance (2) irrationnalité
(3) inertie ?
-- ;-)
On 25 Jul 2004 11:55:37 +0200, Gabriel Dos Reis
<gdr@integrable-solutions.net>:
la réticence à utiliser C++ est lié au moins à deux facteurs :
(1) ignorance
(2) irrationnalité
la réticence à utiliser C++ est lié au moins à deux facteurs : (1) ignorance (2) irrationnalité
(3) inertie ?
-- ;-)
Gabriel Dos Reis
Martinez Jerome writes:
| Fabien LE LEZ wrote: | | > J'ai d'ailleurs l'impression qu'ils se ressemblent beaucoup : à chaque | > fois que quelqu'un donne des arguments en faveur de QT, ils valent | > aussi pour wxWidgets :-) | > | | Ils se ressemblent pas mal effectivement (C++, API indépendante de la | plate-forme etc...), mais ont des philosophies différentes : | - Qt est commercial : entreprise qui developpe, une licence payante | (petite exception : il existe une version GPL pour certains OS, mais | pas Widows), mais un developpement plus poussé (plus de | fonctionnalités) | - WxWidgets est non commercial : un licence plus permissive (LGPL),
C'est la première fois que je vois « LGPL » qualifiée de « plus permissive » ;-/
| Fabien LE LEZ wrote:
|
| > J'ai d'ailleurs l'impression qu'ils se ressemblent beaucoup : à chaque
| > fois que quelqu'un donne des arguments en faveur de QT, ils valent
| > aussi pour wxWidgets :-)
| >
|
| Ils se ressemblent pas mal effectivement (C++, API indépendante de la
| plate-forme etc...), mais ont des philosophies différentes :
| - Qt est commercial : entreprise qui developpe, une licence payante
| (petite exception : il existe une version GPL pour certains OS, mais
| pas Widows), mais un developpement plus poussé (plus de
| fonctionnalités)
| - WxWidgets est non commercial : un licence plus permissive (LGPL),
C'est la première fois que je vois « LGPL » qualifiée de « plus
permissive » ;-/
| Fabien LE LEZ wrote: | | > J'ai d'ailleurs l'impression qu'ils se ressemblent beaucoup : à chaque | > fois que quelqu'un donne des arguments en faveur de QT, ils valent | > aussi pour wxWidgets :-) | > | | Ils se ressemblent pas mal effectivement (C++, API indépendante de la | plate-forme etc...), mais ont des philosophies différentes : | - Qt est commercial : entreprise qui developpe, une licence payante | (petite exception : il existe une version GPL pour certains OS, mais | pas Widows), mais un developpement plus poussé (plus de | fonctionnalités) | - WxWidgets est non commercial : un licence plus permissive (LGPL),
C'est la première fois que je vois « LGPL » qualifiée de « plus permissive » ;-/
-- Gaby
Gabriel Dos Reis
Matthieu Moy writes:
| Et tu peux très bien arrêter le développement d'un logiciel sans pour | autant être en faillite. Que je sache, MS est loin d'être en faillite,
Oui, mais une licence GPL y changera rarement quoi que ce soit.
| Et tu peux très bien arrêter le développement d'un logiciel sans pour | autant être en faillite. Que je sache, MS est loin d'être en faillite,
Oui, mais une licence GPL y changera rarement quoi que ce soit.
-- Gaby
Gabriel Dos Reis
Fabien LE LEZ writes:
| On Wed, 21 Jul 2004 02:18:14 +0200, "Alain Naigeon" | : | | >C'est un fait, mais, sans vouloir lancer une guéguerre, c'est peut-être | >l'environnement lui-même (matériel & OS propriétaires en nette minorité) | >qui génère le danger | | Quelle qu'en soit la cause, le fait est là : certains logiciels | disparaissent, et tous ceux qui ont investi sur la pérennité de ces | logiciels n'ont plus que leurs yeux pour pleurer.
Oui, ceci peut arriver pour un logiciel open-source/libre ou non.
-- Gaby
Fabien LE LEZ <gramster@gramster.com> writes:
| On Wed, 21 Jul 2004 02:18:14 +0200, "Alain Naigeon"
| <anaigeon@free.fr>:
|
| >C'est un fait, mais, sans vouloir lancer une guéguerre, c'est peut-être
| >l'environnement lui-même (matériel & OS propriétaires en nette minorité)
| >qui génère le danger
|
| Quelle qu'en soit la cause, le fait est là : certains logiciels
| disparaissent, et tous ceux qui ont investi sur la pérennité de ces
| logiciels n'ont plus que leurs yeux pour pleurer.
Oui, ceci peut arriver pour un logiciel open-source/libre ou non.
| On Wed, 21 Jul 2004 02:18:14 +0200, "Alain Naigeon" | : | | >C'est un fait, mais, sans vouloir lancer une guéguerre, c'est peut-être | >l'environnement lui-même (matériel & OS propriétaires en nette minorité) | >qui génère le danger | | Quelle qu'en soit la cause, le fait est là : certains logiciels | disparaissent, et tous ceux qui ont investi sur la pérennité de ces | logiciels n'ont plus que leurs yeux pour pleurer.
Oui, ceci peut arriver pour un logiciel open-source/libre ou non.
-- Gaby
Fabien LE LEZ
On 25 Jul 2004 12:03:12 +0200, Gabriel Dos Reis :
| - WxWidgets est non commercial : un licence plus permissive (LGPL),
C'est la première fois que je vois « LGPL » qualifiée de « plus permissive » ;-/
J'avoue n'avoir jamais bien compris la GPL, mais en tout cas la LGPL de wxWidgets (qui ressemble à la licence BSD d'ailleurs) me paraît tout ce qu'il y a de plus permissif : en gros, un logiciel utilisant wxWidgets peut être distribué selon le bon gré du programmeur, i.e. soit libre, soit commercial.
-- ;-)
On 25 Jul 2004 12:03:12 +0200, Gabriel Dos Reis
<gdr@integrable-solutions.net>:
| - WxWidgets est non commercial : un licence plus permissive (LGPL),
C'est la première fois que je vois « LGPL » qualifiée de « plus
permissive » ;-/
J'avoue n'avoir jamais bien compris la GPL, mais en tout cas la LGPL
de wxWidgets (qui ressemble à la licence BSD d'ailleurs) me paraît
tout ce qu'il y a de plus permissif : en gros, un logiciel utilisant
wxWidgets peut être distribué selon le bon gré du programmeur, i.e.
soit libre, soit commercial.
| - WxWidgets est non commercial : un licence plus permissive (LGPL),
C'est la première fois que je vois « LGPL » qualifiée de « plus permissive » ;-/
J'avoue n'avoir jamais bien compris la GPL, mais en tout cas la LGPL de wxWidgets (qui ressemble à la licence BSD d'ailleurs) me paraît tout ce qu'il y a de plus permissif : en gros, un logiciel utilisant wxWidgets peut être distribué selon le bon gré du programmeur, i.e. soit libre, soit commercial.
-- ;-)
Fabien LE LEZ
On 25 Jul 2004 12:03:12 +0200, Gabriel Dos Reis :
| - WxWidgets est non commercial : un licence plus permissive (LGPL),
C'est la première fois que je vois « LGPL » qualifiée de « plus permissive » ;-/
LGPL est plus permissive que GPL, non ?
-- ;-)
On 25 Jul 2004 12:03:12 +0200, Gabriel Dos Reis
<gdr@integrable-solutions.net>:
| - WxWidgets est non commercial : un licence plus permissive (LGPL),
C'est la première fois que je vois « LGPL » qualifiée de « plus
permissive » ;-/
| - WxWidgets est non commercial : un licence plus permissive (LGPL),
C'est la première fois que je vois « LGPL » qualifiée de « plus permissive » ;-/
LGPL est plus permissive que GPL, non ?
-- ;-)
Gabriel Dos Reis
Fabien LE LEZ writes:
| On 25 Jul 2004 12:03:12 +0200, Gabriel Dos Reis | : | | >| - WxWidgets est non commercial : un licence plus permissive (LGPL), | > | >C'est la première fois que je vois « LGPL » qualifiée de « plus | >permissive » ;-/ | | LGPL est plus permissive que GPL, non ?
C'est sûr qu'on peut trouver plus restrictif ;-)
-- Gaby
Fabien LE LEZ <gramster@gramster.com> writes:
| On 25 Jul 2004 12:03:12 +0200, Gabriel Dos Reis
| <gdr@integrable-solutions.net>:
|
| >| - WxWidgets est non commercial : un licence plus permissive (LGPL),
| >
| >C'est la première fois que je vois « LGPL » qualifiée de « plus
| >permissive » ;-/
|
| LGPL est plus permissive que GPL, non ?
| On 25 Jul 2004 12:03:12 +0200, Gabriel Dos Reis | : | | >| - WxWidgets est non commercial : un licence plus permissive (LGPL), | > | >C'est la première fois que je vois « LGPL » qualifiée de « plus | >permissive » ;-/ | | LGPL est plus permissive que GPL, non ?
C'est sûr qu'on peut trouver plus restrictif ;-)
-- Gaby
Martinez Jerome
Gabriel Dos Reis wrote:
C'est la première fois que je vois « LGPL » qualifiée de « plus permissive » ;-/
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)
Gabriel Dos Reis wrote:
C'est la première fois que je vois « LGPL » qualifiée de « plus
permissive » ;-/
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)
C'est la première fois que je vois « LGPL » qualifiée de « plus permissive » ;-/
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)
Matthieu Moy
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.
-- Matthieu
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.
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.
