<i>>> Est-il prevu de supprimer l'utilisation du preprocesseur ? (cf http://libsigc.sourceforge.net/(...) )
Ca m'étonnerait pas mal. Ce préprocesseur est dur à accepter au début, mais par la suite on le bénit. Ca rend le code très propre. C'est un avis personnel, évidemment.
Le preprocesseur a ete choisit comme solution par Trolltech car les compilateurs C++ il y a 6-7 ans ne supportaient pas correctement les templates (et donc la STL). Mais actuellement ca a changer.
ligsigc++ est la preuve que l'on peut implementer les signaux avec du vrai C++ standard et que c'est pas plus compliqué à utiliser et que ca marche bien.
--- Qt utilise déjà les templates et propose même une réimplémentation d'une partie de la STL...
C'est exactement ce que je veux pas !
Au lieu d'utiliser l'existant on re-invente
Donc on doit apprendre 2 manieres de faire, la maniere C++ standard et puis la maniere Qt.
---
<i>>> Est-il prevu des intégrations de classes KDE au sein de Qt (par exemple la boite de dialogue d'ouverture/sauvegarde de fichiers ect... pour eviter les IFDEF)
>> D'une maniere générale envisagez-vous un rapprochement profond entre Qt et les classes KDE ?
Tu connais la réponse pourtant... ;-) Ces deux projets n'ont rien à voir. Demande à KDE d'être plus multiplateforme et n'utilise que ces bibliothèques là...
Si c'etait aussi evident que ca, les gens ne feraient pas des threads impressionnants sur la mailing-list et sur dot.kde.org à ce sujet (j'ai pas retrouve le post en question). Je trouve ridicule de devoir faire des IFDEF juste pour une boite de dialogue qui n'a en soit rien de spécifique a KDE, pas toi ?
---
<i>>> comptez-vous a long terme abandonner C++ pour un autre langage ?
Comptez-vous vous saborder vous-même en recommançant à zéro le travail de tant d'années ? ;-) Non, plus sérieusement, je ne suis pas, excuse-moi : à quoi penses-tu comme langage ?
Ba c'est simple, ceux qui ont codé des libs pour COBOL j'espere que depuis ils ont re-ecrit leur libs pour un langage plus moderne.
Dans 10 ou 15 ans il en restera quoi du C++ ? (j'ai bien precisé long-terme dans ma question).
---
<i>>>Personnellement sur le long terme j'aimerais bien que Qt soit:
>> - basé sur du C++ moderne
C'est-à-dire ? Et ça t'apporterait quoi ? C'est juste une bibliothèque...
C++ moderne = templates, STL ect...
ce que ca apporte me parait evident. moins de temps de developpement, plus facile, standard C++ et pas de preproc (donc compatible avec tous les outils de dev qui supportent le C++) ect...
---
<i>>> - une intégration parfaite à KDE
Faut vraiment que tu m'explique ça...
Avant Qt3, les applis avaient une allure differente entre les applis KDE et Qt. maintenant au niveau developpement il y a encore des problemes d'intégration (toujours le meme exemple des IFDEF pour les boites de dialogues).
[^] # Re: Posez vos questions à Trolltech
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Posez vos questions à Trolltech. Évalué à 1.
Ca m'étonnerait pas mal. Ce préprocesseur est dur à accepter au début, mais par la suite on le bénit. Ca rend le code très propre. C'est un avis personnel, évidemment.
Le preprocesseur a ete choisit comme solution par Trolltech car les compilateurs C++ il y a 6-7 ans ne supportaient pas correctement les templates (et donc la STL). Mais actuellement ca a changer.
ligsigc++ est la preuve que l'on peut implementer les signaux avec du vrai C++ standard et que c'est pas plus compliqué à utiliser et que ca marche bien.
---
Qt utilise déjà les templates et propose même une réimplémentation d'une partie de la STL...
C'est exactement ce que je veux pas !
Au lieu d'utiliser l'existant on re-invente
Donc on doit apprendre 2 manieres de faire, la maniere C++ standard et puis la maniere Qt.
---
<i>>> Est-il prevu des intégrations de classes KDE au sein de Qt (par exemple la boite de dialogue d'ouverture/sauvegarde de fichiers ect... pour eviter les IFDEF)
>> D'une maniere générale envisagez-vous un rapprochement profond entre Qt et les classes KDE ?
Tu connais la réponse pourtant... ;-) Ces deux projets n'ont rien à voir. Demande à KDE d'être plus multiplateforme et n'utilise que ces bibliothèques là...
Si c'etait aussi evident que ca, les gens ne feraient pas des threads impressionnants sur la mailing-list et sur dot.kde.org à ce sujet (j'ai pas retrouve le post en question). Je trouve ridicule de devoir faire des IFDEF juste pour une boite de dialogue qui n'a en soit rien de spécifique a KDE, pas toi ?
---
<i>>> comptez-vous a long terme abandonner C++ pour un autre langage ?
Comptez-vous vous saborder vous-même en recommançant à zéro le travail de tant d'années ? ;-) Non, plus sérieusement, je ne suis pas, excuse-moi : à quoi penses-tu comme langage ?
Ba c'est simple, ceux qui ont codé des libs pour COBOL j'espere que depuis ils ont re-ecrit leur libs pour un langage plus moderne.
Dans 10 ou 15 ans il en restera quoi du C++ ? (j'ai bien precisé long-terme dans ma question).
---
<i>>>Personnellement sur le long terme j'aimerais bien que Qt soit:
>> - basé sur du C++ moderne
C'est-à-dire ? Et ça t'apporterait quoi ? C'est juste une bibliothèque...
C++ moderne = templates, STL ect...
ce que ca apporte me parait evident. moins de temps de developpement, plus facile, standard C++ et pas de preproc (donc compatible avec tous les outils de dev qui supportent le C++) ect...
---
<i>>> - une intégration parfaite à KDE
Faut vraiment que tu m'explique ça...
Avant Qt3, les applis avaient une allure differente entre les applis KDE et Qt. maintenant au niveau developpement il y a encore des problemes d'intégration (toujours le meme exemple des IFDEF pour les boites de dialogues).