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...)
On Tue, 20 Jul 2004 17:54:30 +0200, Martinez Jerome :
- Qt est commercial : entreprise qui developpe
Au fait, si jamais l'entreprise qui développe fait faillite, le développement pourra-t-il continuer ?
Dans ce cas précis il me semble que trolltech passe tous ses sources en license GPL au bout de 2 ans, ou bien si la société fait faillite. Je n'ai pas vérifié l'information, je peux me tromper.
Christophe
-- Christophe de Vienne
Fabien LE LEZ wrote:
On Tue, 20 Jul 2004 17:54:30 +0200, Martinez Jerome
<jerome.martinez@aenlever-orangefrance.com.invalid>:
- Qt est commercial : entreprise qui developpe
Au fait, si jamais l'entreprise qui développe fait faillite, le
développement pourra-t-il continuer ?
Dans ce cas précis il me semble que trolltech passe tous ses sources en
license GPL au bout de 2 ans, ou bien si la société fait faillite. Je
n'ai pas vérifié l'information, je peux me tromper.
On Tue, 20 Jul 2004 17:54:30 +0200, Martinez Jerome :
- Qt est commercial : entreprise qui developpe
Au fait, si jamais l'entreprise qui développe fait faillite, le développement pourra-t-il continuer ?
Dans ce cas précis il me semble que trolltech passe tous ses sources en license GPL au bout de 2 ans, ou bien si la société fait faillite. Je n'ai pas vérifié l'information, je peux me tromper.
Christophe
-- Christophe de Vienne
Arnaud Debaene
Fabien LE LEZ wrote:
On Tue, 20 Jul 2004 18:07:53 +0200, "Mickael Pointier" :
Il me semble qu'il y aurait moins de librairies écrites en C, et plus écrites en C++ si le format binaire des .LIB était standardisé...
Mouais... la quasi-totalité des bibliothèques écrites en C que j'utilise sont fournies sous forme de sources (parfois assez chiants à compiler, d'ailleurs), rarement sous forme précompilée (.lib/.a). Du coup, l'argument ne tient pas.
Si, il tient encore du fait des disparités et des "bug-incompatibilités" des compilateurs entre eux :-(
Arnaud
Fabien LE LEZ wrote:
On Tue, 20 Jul 2004 18:07:53 +0200, "Mickael Pointier"
<mpointier@edengames.moc>:
Il me semble qu'il y aurait moins de librairies écrites en C, et plus
écrites en C++ si le format binaire des .LIB était standardisé...
Mouais... la quasi-totalité des bibliothèques écrites en C que
j'utilise sont fournies sous forme de sources (parfois assez chiants à
compiler, d'ailleurs), rarement sous forme précompilée (.lib/.a). Du
coup, l'argument ne tient pas.
Si, il tient encore du fait des disparités et des "bug-incompatibilités" des
compilateurs entre eux :-(
On Tue, 20 Jul 2004 18:07:53 +0200, "Mickael Pointier" :
Il me semble qu'il y aurait moins de librairies écrites en C, et plus écrites en C++ si le format binaire des .LIB était standardisé...
Mouais... la quasi-totalité des bibliothèques écrites en C que j'utilise sont fournies sous forme de sources (parfois assez chiants à compiler, d'ailleurs), rarement sous forme précompilée (.lib/.a). Du coup, l'argument ne tient pas.
Si, il tient encore du fait des disparités et des "bug-incompatibilités" des compilateurs entre eux :-(
Arnaud
Loïc Joly
Christophe de VIENNE wrote:
Fabien LE LEZ wrote:
On Tue, 20 Jul 2004 17:54:30 +0200, Martinez Jerome :
- Qt est commercial : entreprise qui developpe
Au fait, si jamais l'entreprise qui développe fait faillite, le développement pourra-t-il continuer ?
Dans ce cas précis il me semble que trolltech passe tous ses sources en license GPL au bout de 2 ans, ou bien si la société fait faillite. Je n'ai pas vérifié l'information, je peux me tromper.
Le 2 ans, j'en sais rien, le si faillite, je confirme : http://www.kde.org/whatiskde/kdefreeqtfoundation.php
-- Loïc
Christophe de VIENNE wrote:
Fabien LE LEZ wrote:
On Tue, 20 Jul 2004 17:54:30 +0200, Martinez Jerome
<jerome.martinez@aenlever-orangefrance.com.invalid>:
- Qt est commercial : entreprise qui developpe
Au fait, si jamais l'entreprise qui développe fait faillite, le
développement pourra-t-il continuer ?
Dans ce cas précis il me semble que trolltech passe tous ses sources en
license GPL au bout de 2 ans, ou bien si la société fait faillite. Je
n'ai pas vérifié l'information, je peux me tromper.
Le 2 ans, j'en sais rien, le si faillite, je confirme :
http://www.kde.org/whatiskde/kdefreeqtfoundation.php
On Tue, 20 Jul 2004 17:54:30 +0200, Martinez Jerome :
- Qt est commercial : entreprise qui developpe
Au fait, si jamais l'entreprise qui développe fait faillite, le développement pourra-t-il continuer ?
Dans ce cas précis il me semble que trolltech passe tous ses sources en license GPL au bout de 2 ans, ou bien si la société fait faillite. Je n'ai pas vérifié l'information, je peux me tromper.
Le 2 ans, j'en sais rien, le si faillite, je confirme : http://www.kde.org/whatiskde/kdefreeqtfoundation.php
-- Loïc
Alain Naigeon
"Fabien LE LEZ" a écrit dans le message news:
On Tue, 20 Jul 2004 17:54:30 +0200, Martinez Jerome :
- Qt est commercial : entreprise qui developpe
Au fait, si jamais l'entreprise qui développe fait faillite, le développement pourra-t-il continuer ?
A question classique, réponse classique (et souvent vérifiée) : un bon logiciel trouve un repreneur, tout simplement en raison du potentiel de sa base installée.
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message news:
18hqf0lthki9c676apkrls2cvaqs5dsoc3@4ax.com...
On Tue, 20 Jul 2004 17:54:30 +0200, Martinez Jerome
<jerome.martinez@aenlever-orangefrance.com.invalid>:
- Qt est commercial : entreprise qui developpe
Au fait, si jamais l'entreprise qui développe fait faillite, le
développement pourra-t-il continuer ?
A question classique, réponse classique (et souvent vérifiée) :
un bon logiciel trouve un repreneur, tout simplement en
raison du potentiel de sa base installée.
--
Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - anaigeon@free.fr - Strasbourg, France
On Tue, 20 Jul 2004 17:54:30 +0200, Martinez Jerome :
- Qt est commercial : entreprise qui developpe
Au fait, si jamais l'entreprise qui développe fait faillite, le développement pourra-t-il continuer ?
A question classique, réponse classique (et souvent vérifiée) : un bon logiciel trouve un repreneur, tout simplement en raison du potentiel de sa base installée.
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
Loïc Joly
Vince44 wrote:
Pourquoi éxiste-t-il 873 redéfinition d'un entier 32 bit?
Un des problèmes du C++ est que "typedef" se comporte un peu comme "#define" : il ne déclare pas un nouveau type, mais un nouveau nom pour le même type. [...]
Et bien ça promet, on a pas fini d'en chier... Ceux à qui on interdira le #define ne manquerons pas de reprendre leurs mauvaises habitudes avec le typedef...
Sauf que l'habitude est moins mauvaise (et il y a des cas où elle est justifiée), puisqu'au moins les noms typedefés respectent les portées.
Les programmeur de chez MS sont payés au #define?
M'en parle pas... Cela dit, on travaille là avec des méthodes mises au point au début de Windows, et jamais changées depuis.
Que ça soit vieux c'est une chose, que ça n'évolue pas ça en est une autre...
Ca évolue. Il faut regarder du côté de .NET pour voir ça.
[...]
De plus, comme std::string est un template (basic_string <char, quelque chose d'autre>), peu de compilateurs le supportent vraiment, i.e. avec des messages d'erreurs clairs. Et du coup, même wxWidgets définit sa propre classe wxString, non-template ! ~_~
Et là c'est le drame...
Il est aussi possible que std::string ne soit pas suffisant. En particulier, j'ai entendu dire (mais j'y connais rien là dedans) qu'une QString (la version QT d'une chaîne) possèdait des fonctions d'internationnalisation intéressantes, plus par exemple que std::wstring.
Je n'oubli pas, je veux bien comprendre que C++ soit agé, mais il ne me semble pas que le problème soit C++... Il me semble que c'est surtout ce qui se fait autour. ça me donne l'impréssion que C++ est une vitrine plus présentable que C, mais seulement une vitrine. Je ne nie pas l'existence de C++ dans l'industrie, simplement si il faut faire du C dès qu'on veut du portable ou du proche système on tape dans le C...
Au plus proche du système, oui, puisque les systèmes se doivent d'être compatible avec n'importe quel langage, et donc utilisent le plus petit dénominateur commun : le C. Mais "personne" ne programme à ce niveau là. La première chose à faire quand on souhaite utiliser une fonction système est de wrapper ça en C++. Ne serait-ce que pour bénéficier du RAII.
Je me demande si il ne manque pas un leader dans le process d'évolution du langage C++: quelqu'un qui aurait dit à MS & cie "démerdez-vous pour inclure la STDLib et écrire des wrappers pour vos API, vous avez 5 ans."
C'est un peu le rôle qu'Herb Sutter est sensé remplir chez Microsoft, par exemple, mais avec aussi une composante dans l'autre sens.
Moi j'aimerais bien voir "deprecated" en face de toutes les fonctions C dans la MSDN... D'ailleurs je me demande si ils ont écrit des wrappers pour C#, dans ce cas ça signifirait qu'on ne les aura jamais pour C++. C++ serait la génération sacrifiée...
Par essence, les wrappers C# sont aussi des wrappers VB et des wrappers C++/CLI. Mais je ne suis actuellement (et après essai grandeur réelle) que moyennement convaincu des possibilités de mixer managed C++ et C++ classique. Ca produit un style d'écriture trop lourd.
N'oulie pas aussi que plein de programmeurs C se croient capables de bien programmer en C++.
Je ne l'oubli pas, et c'est précisément pour ne pas les réjoindre que je fais cette démarche... personnelement j'ai plutôt une culture objet, mais actuellement en C/C++ je suis obligé de la mettre de côté...
Je ne vois pas pourquoi.
Merci pour tout, même si je suis un peu déçu. J'avoue que m'embarquer dans du borland ne m'inspire pas vraiment, j'aurait préféré un truc plus portable. Par exemple eclipse + stl + compilo "propre" multiplate-forme
Qu'apporte un compilo multi plateformes par rapport à n compilos chacun suffisemment proche du standard ? Avec les dernières versions, notre code VC++ compile en général directement sous gcc, et réciproquement.
(gcc? dispo sous windows?).
Oui (regarde dev-c++ ou cygwin), par contre, je trouve les temps de compilation assez énormes, même sur des hello world like (le genre de programmes que je poste ici) et sur les quelques benchs réalisés, VC++ optimisait bien mieux le code généré. Si vous avez l'habitude de l'utiliser (la version 7.1, bien sur), je ne vois pas vraiment de raison de changer.
Quand on discutait C++/Java les gens étaient plus enthousiastes sur les possibilités de dev propres et portables avec C++.
C'est (du moins pour la partie portable ;)) ce qu'on fait quotidiennement au boulot.
Sans remettre en cause le language, il semblerait que s'outiller correctement ne soit pas si simple, en tout cas à mille lieues de ce qui est offert en Java...
La où C++ me semble en retard, c'est du côté des outils plus évolués, genre case. La syntaxe complexe du C++ ne doit pas y être étrangère. J'ai par exemple testé Together récemment, et même si c'est ce que j'ai vu de mieux pour l'instant dans le genre, il y a à mon avis encore une étape à franchir.
-- Loïc
Vince44 wrote:
Pourquoi éxiste-t-il 873 redéfinition d'un entier 32 bit?
Un des problèmes du C++ est que "typedef" se comporte un peu comme
"#define" : il ne déclare pas un nouveau type, mais un nouveau nom
pour le même type.
[...]
Et bien ça promet, on a pas fini d'en chier... Ceux à qui on interdira
le #define ne manquerons pas de reprendre leurs mauvaises habitudes
avec le typedef...
Sauf que l'habitude est moins mauvaise (et il y a des cas où elle est
justifiée), puisqu'au moins les noms typedefés respectent les portées.
Les programmeur de chez MS sont payés au #define?
M'en parle pas...
Cela dit, on travaille là avec des méthodes mises au point au début de
Windows, et jamais changées depuis.
Que ça soit vieux c'est une chose, que ça n'évolue pas ça en est une
autre...
Ca évolue. Il faut regarder du côté de .NET pour voir ça.
[...]
De plus, comme std::string est un template (basic_string <char,
quelque chose d'autre>), peu de compilateurs le supportent vraiment,
i.e. avec des messages d'erreurs clairs. Et du coup, même wxWidgets
définit sa propre classe wxString, non-template ! ~_~
Et là c'est le drame...
Il est aussi possible que std::string ne soit pas suffisant. En
particulier, j'ai entendu dire (mais j'y connais rien là dedans) qu'une
QString (la version QT d'une chaîne) possèdait des fonctions
d'internationnalisation intéressantes, plus par exemple que std::wstring.
Je n'oubli pas, je veux bien comprendre que C++ soit agé, mais il ne
me semble pas que le problème soit C++... Il me semble que c'est
surtout ce qui se fait autour. ça me donne l'impréssion que C++ est
une vitrine plus présentable que C, mais seulement une vitrine. Je ne
nie pas l'existence de C++ dans l'industrie, simplement si il faut
faire du C dès qu'on veut du portable ou du proche système on tape
dans le C...
Au plus proche du système, oui, puisque les systèmes se doivent d'être
compatible avec n'importe quel langage, et donc utilisent le plus petit
dénominateur commun : le C. Mais "personne" ne programme à ce niveau là.
La première chose à faire quand on souhaite utiliser une fonction
système est de wrapper ça en C++. Ne serait-ce que pour bénéficier du RAII.
Je me demande si il ne manque pas un leader dans le
process d'évolution du langage C++: quelqu'un qui aurait dit à MS &
cie "démerdez-vous pour inclure la STDLib et écrire des wrappers pour
vos API, vous avez 5 ans."
C'est un peu le rôle qu'Herb Sutter est sensé remplir chez Microsoft,
par exemple, mais avec aussi une composante dans l'autre sens.
Moi j'aimerais bien voir "deprecated" en
face de toutes les fonctions C dans la MSDN... D'ailleurs je me
demande si ils ont écrit des wrappers pour C#, dans ce cas ça
signifirait qu'on ne les aura jamais pour C++. C++ serait la
génération sacrifiée...
Par essence, les wrappers C# sont aussi des wrappers VB et des wrappers
C++/CLI. Mais je ne suis actuellement (et après essai grandeur réelle)
que moyennement convaincu des possibilités de mixer managed C++ et C++
classique. Ca produit un style d'écriture trop lourd.
N'oulie pas aussi que plein de programmeurs C se croient capables de
bien programmer en C++.
Je ne l'oubli pas, et c'est précisément pour ne pas les réjoindre que
je fais cette démarche... personnelement j'ai plutôt une culture
objet, mais actuellement en C/C++ je suis obligé de la mettre de
côté...
Je ne vois pas pourquoi.
Merci pour tout, même si je suis un peu déçu. J'avoue que m'embarquer
dans du borland ne m'inspire pas vraiment, j'aurait préféré un truc
plus portable. Par exemple eclipse + stl + compilo "propre"
multiplate-forme
Qu'apporte un compilo multi plateformes par rapport à n compilos chacun
suffisemment proche du standard ? Avec les dernières versions, notre
code VC++ compile en général directement sous gcc, et réciproquement.
(gcc? dispo sous windows?).
Oui (regarde dev-c++ ou cygwin), par contre, je trouve les temps de
compilation assez énormes, même sur des hello world like (le genre de
programmes que je poste ici) et sur les quelques benchs réalisés, VC++
optimisait bien mieux le code généré. Si vous avez l'habitude de
l'utiliser (la version 7.1, bien sur), je ne vois pas vraiment de raison
de changer.
Quand on discutait
C++/Java les gens étaient plus enthousiastes sur les possibilités de
dev propres et portables avec C++.
C'est (du moins pour la partie portable ;)) ce qu'on fait
quotidiennement au boulot.
Sans remettre en cause le language,
il semblerait que s'outiller correctement ne soit pas si simple, en
tout cas à mille lieues de ce qui est offert en Java...
La où C++ me semble en retard, c'est du côté des outils plus évolués,
genre case. La syntaxe complexe du C++ ne doit pas y être étrangère.
J'ai par exemple testé Together récemment, et même si c'est ce que j'ai
vu de mieux pour l'instant dans le genre, il y a à mon avis encore une
étape à franchir.
Pourquoi éxiste-t-il 873 redéfinition d'un entier 32 bit?
Un des problèmes du C++ est que "typedef" se comporte un peu comme "#define" : il ne déclare pas un nouveau type, mais un nouveau nom pour le même type. [...]
Et bien ça promet, on a pas fini d'en chier... Ceux à qui on interdira le #define ne manquerons pas de reprendre leurs mauvaises habitudes avec le typedef...
Sauf que l'habitude est moins mauvaise (et il y a des cas où elle est justifiée), puisqu'au moins les noms typedefés respectent les portées.
Les programmeur de chez MS sont payés au #define?
M'en parle pas... Cela dit, on travaille là avec des méthodes mises au point au début de Windows, et jamais changées depuis.
Que ça soit vieux c'est une chose, que ça n'évolue pas ça en est une autre...
Ca évolue. Il faut regarder du côté de .NET pour voir ça.
[...]
De plus, comme std::string est un template (basic_string <char, quelque chose d'autre>), peu de compilateurs le supportent vraiment, i.e. avec des messages d'erreurs clairs. Et du coup, même wxWidgets définit sa propre classe wxString, non-template ! ~_~
Et là c'est le drame...
Il est aussi possible que std::string ne soit pas suffisant. En particulier, j'ai entendu dire (mais j'y connais rien là dedans) qu'une QString (la version QT d'une chaîne) possèdait des fonctions d'internationnalisation intéressantes, plus par exemple que std::wstring.
Je n'oubli pas, je veux bien comprendre que C++ soit agé, mais il ne me semble pas que le problème soit C++... Il me semble que c'est surtout ce qui se fait autour. ça me donne l'impréssion que C++ est une vitrine plus présentable que C, mais seulement une vitrine. Je ne nie pas l'existence de C++ dans l'industrie, simplement si il faut faire du C dès qu'on veut du portable ou du proche système on tape dans le C...
Au plus proche du système, oui, puisque les systèmes se doivent d'être compatible avec n'importe quel langage, et donc utilisent le plus petit dénominateur commun : le C. Mais "personne" ne programme à ce niveau là. La première chose à faire quand on souhaite utiliser une fonction système est de wrapper ça en C++. Ne serait-ce que pour bénéficier du RAII.
Je me demande si il ne manque pas un leader dans le process d'évolution du langage C++: quelqu'un qui aurait dit à MS & cie "démerdez-vous pour inclure la STDLib et écrire des wrappers pour vos API, vous avez 5 ans."
C'est un peu le rôle qu'Herb Sutter est sensé remplir chez Microsoft, par exemple, mais avec aussi une composante dans l'autre sens.
Moi j'aimerais bien voir "deprecated" en face de toutes les fonctions C dans la MSDN... D'ailleurs je me demande si ils ont écrit des wrappers pour C#, dans ce cas ça signifirait qu'on ne les aura jamais pour C++. C++ serait la génération sacrifiée...
Par essence, les wrappers C# sont aussi des wrappers VB et des wrappers C++/CLI. Mais je ne suis actuellement (et après essai grandeur réelle) que moyennement convaincu des possibilités de mixer managed C++ et C++ classique. Ca produit un style d'écriture trop lourd.
N'oulie pas aussi que plein de programmeurs C se croient capables de bien programmer en C++.
Je ne l'oubli pas, et c'est précisément pour ne pas les réjoindre que je fais cette démarche... personnelement j'ai plutôt une culture objet, mais actuellement en C/C++ je suis obligé de la mettre de côté...
Je ne vois pas pourquoi.
Merci pour tout, même si je suis un peu déçu. J'avoue que m'embarquer dans du borland ne m'inspire pas vraiment, j'aurait préféré un truc plus portable. Par exemple eclipse + stl + compilo "propre" multiplate-forme
Qu'apporte un compilo multi plateformes par rapport à n compilos chacun suffisemment proche du standard ? Avec les dernières versions, notre code VC++ compile en général directement sous gcc, et réciproquement.
(gcc? dispo sous windows?).
Oui (regarde dev-c++ ou cygwin), par contre, je trouve les temps de compilation assez énormes, même sur des hello world like (le genre de programmes que je poste ici) et sur les quelques benchs réalisés, VC++ optimisait bien mieux le code généré. Si vous avez l'habitude de l'utiliser (la version 7.1, bien sur), je ne vois pas vraiment de raison de changer.
Quand on discutait C++/Java les gens étaient plus enthousiastes sur les possibilités de dev propres et portables avec C++.
C'est (du moins pour la partie portable ;)) ce qu'on fait quotidiennement au boulot.
Sans remettre en cause le language, il semblerait que s'outiller correctement ne soit pas si simple, en tout cas à mille lieues de ce qui est offert en Java...
La où C++ me semble en retard, c'est du côté des outils plus évolués, genre case. La syntaxe complexe du C++ ne doit pas y être étrangère. J'ai par exemple testé Together récemment, et même si c'est ce que j'ai vu de mieux pour l'instant dans le genre, il y a à mon avis encore une étape à franchir.
-- Loïc
Matthieu Moy
Christophe de VIENNE writes:
Dans ce cas précis il me semble que trolltech passe tous ses sources en license GPL au bout de 2 ans, ou bien si la société fait faillite.
Trolltech passe tous les sources de Qt en licence GPL, point.
Et il y a une double licence avec une licence commerciale et propriétaire pour ceux que la GPL dérange.
-- Matthieu
Christophe de VIENNE <cdevienne@alphacent.com> writes:
Dans ce cas précis il me semble que trolltech passe tous ses sources
en license GPL au bout de 2 ans, ou bien si la société fait faillite.
Trolltech passe tous les sources de Qt en licence GPL, point.
Et il y a une double licence avec une licence commerciale et
propriétaire pour ceux que la GPL dérange.
Dans ce cas précis il me semble que trolltech passe tous ses sources en license GPL au bout de 2 ans, ou bien si la société fait faillite.
Trolltech passe tous les sources de Qt en licence GPL, point.
Et il y a une double licence avec une licence commerciale et propriétaire pour ceux que la GPL dérange.
-- Matthieu
Loïc Joly
Fabien LE LEZ wrote:
On Mon, 19 Jul 2004 21:57:31 +0200, Loïc Joly :
[...] QT [...] WxWidgets est aussi souvent cité.
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 :-)
Il y a quand même des différences, je pense, et même en dehors de la license.
Par exemple, il me semble que wxWidgets utilise des event map à base de macro et d'allure rébarbative (j'ai jamais essayé, mais ça m'a l'air assez statique et surtout centralisé), alors que le mécanisme de QT de signal/slot me semble plus flexible, même s'il utilise un programme de pré-processing pour les gérer, ce qui est dommage, puisque ces solutions 100% C++ (évolué, mais quand même) existent.
-- Loïc
Fabien LE LEZ wrote:
On Mon, 19 Jul 2004 21:57:31 +0200, Loïc Joly
<loic.actarus.joly@wanadoo.fr>:
[...] QT [...]
WxWidgets est aussi souvent cité.
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 :-)
Il y a quand même des différences, je pense, et même en dehors de la
license.
Par exemple, il me semble que wxWidgets utilise des event map à base de
macro et d'allure rébarbative (j'ai jamais essayé, mais ça m'a l'air
assez statique et surtout centralisé), alors que le mécanisme de QT de
signal/slot me semble plus flexible, même s'il utilise un programme de
pré-processing pour les gérer, ce qui est dommage, puisque ces solutions
100% C++ (évolué, mais quand même) existent.
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 :-)
Il y a quand même des différences, je pense, et même en dehors de la license.
Par exemple, il me semble que wxWidgets utilise des event map à base de macro et d'allure rébarbative (j'ai jamais essayé, mais ça m'a l'air assez statique et surtout centralisé), alors que le mécanisme de QT de signal/slot me semble plus flexible, même s'il utilise un programme de pré-processing pour les gérer, ce qui est dommage, puisque ces solutions 100% C++ (évolué, mais quand même) existent.
-- Loïc
Fabien LE LEZ
On Tue, 20 Jul 2004 21:40:34 +0200, Loïc Joly :
Par exemple, il me semble que wxWidgets utilise des event map à base de macro et d'allure rébarbative (j'ai jamais essayé, mais ça m'a l'air assez statique et surtout centralisé)
En m'y remettant hier soir, je me suis sérieusement demandé si les développeurs de wxWidgets ne sont pas d'anciens développeurs OWL, tellement les interfaces se ressemblent.
-- ;-)
On Tue, 20 Jul 2004 21:40:34 +0200, Loïc Joly
<loic.actarus.joly@wanadoo.fr>:
Par exemple, il me semble que wxWidgets utilise des event map à base de
macro et d'allure rébarbative (j'ai jamais essayé, mais ça m'a l'air
assez statique et surtout centralisé)
En m'y remettant hier soir, je me suis sérieusement demandé si les
développeurs de wxWidgets ne sont pas d'anciens développeurs OWL,
tellement les interfaces se ressemblent.
Par exemple, il me semble que wxWidgets utilise des event map à base de macro et d'allure rébarbative (j'ai jamais essayé, mais ça m'a l'air assez statique et surtout centralisé)
En m'y remettant hier soir, je me suis sérieusement demandé si les développeurs de wxWidgets ne sont pas d'anciens développeurs OWL, tellement les interfaces se ressemblent.
-- ;-)
Matthieu Moy
"Alain Naigeon" writes:
A question classique, réponse classique (et souvent vérifiée) : un bon logiciel trouve un repreneur, tout simplement en raison du potentiel de sa base installée.
Ca, ça dépends de la philosophie de la boite et de la licence du logiciel. Si la licence n'est pas libre (ou en tous cas ne permet pas le "fork"), et si la boite décide d'arrêter le développement du logiciel sans intention de revendre le code, c'est foutu !
-- Matthieu
"Alain Naigeon" <anaigeon@free.fr> writes:
A question classique, réponse classique (et souvent vérifiée) :
un bon logiciel trouve un repreneur, tout simplement en
raison du potentiel de sa base installée.
Ca, ça dépends de la philosophie de la boite et de la licence du
logiciel. Si la licence n'est pas libre (ou en tous cas ne permet pas
le "fork"), et si la boite décide d'arrêter le développement du
logiciel sans intention de revendre le code, c'est foutu !
A question classique, réponse classique (et souvent vérifiée) : un bon logiciel trouve un repreneur, tout simplement en raison du potentiel de sa base installée.
Ca, ça dépends de la philosophie de la boite et de la licence du logiciel. Si la licence n'est pas libre (ou en tous cas ne permet pas le "fork"), et si la boite décide d'arrêter le développement du logiciel sans intention de revendre le code, c'est foutu !
-- Matthieu
Pierrick Ingels
On Tue, 20 Jul 2004 20:47:57 +0200, Loïc Joly wrote:
Christophe de VIENNE wrote:
Fabien LE LEZ wrote:
On Tue, 20 Jul 2004 17:54:30 +0200, Martinez Jerome :
- Qt est commercial : entreprise qui developpe
Au fait, si jamais l'entreprise qui développe fait faillite, le développement pourra-t-il continuer ?
Dans ce cas précis il me semble que trolltech passe tous ses sources en license GPL au bout de 2 ans, ou bien si la société fait faillite. Je n'ai pas vérifié l'information, je peux me tromper.
Le 2 ans, j'en sais rien, le si faillite, je confirme : http://www.kde.org/whatiskde/kdefreeqtfoundation.php
Cet accord semble ne concerner que la version Free Edition de QT. Donc pas la version Windows.
pierrick
On Tue, 20 Jul 2004 20:47:57 +0200, Loïc Joly wrote:
Christophe de VIENNE wrote:
Fabien LE LEZ wrote:
On Tue, 20 Jul 2004 17:54:30 +0200, Martinez Jerome
<jerome.martinez@aenlever-orangefrance.com.invalid>:
- Qt est commercial : entreprise qui developpe
Au fait, si jamais l'entreprise qui développe fait faillite, le
développement pourra-t-il continuer ?
Dans ce cas précis il me semble que trolltech passe tous ses sources en
license GPL au bout de 2 ans, ou bien si la société fait faillite. Je
n'ai pas vérifié l'information, je peux me tromper.
Le 2 ans, j'en sais rien, le si faillite, je confirme :
http://www.kde.org/whatiskde/kdefreeqtfoundation.php
Cet accord semble ne concerner que la version Free Edition de QT. Donc
pas la version Windows.
On Tue, 20 Jul 2004 20:47:57 +0200, Loïc Joly wrote:
Christophe de VIENNE wrote:
Fabien LE LEZ wrote:
On Tue, 20 Jul 2004 17:54:30 +0200, Martinez Jerome :
- Qt est commercial : entreprise qui developpe
Au fait, si jamais l'entreprise qui développe fait faillite, le développement pourra-t-il continuer ?
Dans ce cas précis il me semble que trolltech passe tous ses sources en license GPL au bout de 2 ans, ou bien si la société fait faillite. Je n'ai pas vérifié l'information, je peux me tromper.
Le 2 ans, j'en sais rien, le si faillite, je confirme : http://www.kde.org/whatiskde/kdefreeqtfoundation.php
Cet accord semble ne concerner que la version Free Edition de QT. Donc pas la version Windows.
