Qt contre le monde : Qt pour tout, ou un usage plus raisonné ?

Version imprimable

03/02/2010, 17h55
gbdivers

Qt contre le monde : Qt pour tout, ou un usage plus raisonné ?

Bonjour à tous

Je travaille sur un projet open source créé en 2006 utilisant Qt. Forcement, après tout ce temps, l'architecture du projet commence à être un peu vieille et Qt est mal intégré...
Je suis entrain de rédiger le projet pour une nouvelle version majeure (2.0). Une de mes question concerne les "outils" proposés par Qt et de leurs utilités/avantages :

- Actuellement, nous n'utilisons pas de pointeurs intelligents. Vaut-il mieux utiliser les QPointeurs (qui me semblent limités), boost ou STL ?
- Idem pour les conteneurs, vaut-il mieux utiliser la STL ou QVector et QMap ? Sont-ils plus lent ? plus rapide ? compatible ?
- Certain objets enregistrent des méta-informations à l'aide de classes "faites maison". QVariant et QProperty sont-ils robuste ? rapide ?
- Dériver les classes de QObject permettrait de pouvoir utiliser les signaux/slots, la structure des données en arbre et les QProperty directement. Quel est le coût en terme de rapidité ou de consommation mémoire ?

Plus globalement, que pensez-vous d'une optique "tout Qt" pour un projet (c'est à dire utiliser QVector plutot que std:vector, QXml plutot que xerces, QPointer plutot que auto_ptr, etc.) ?

Merci de vos avis
03/02/2010, 19h47
dourouc05

Salut,

Pour moi, l'idéal reste et restera d'utiliser toujours le même framework, même s'il existe plus optimisé, plus fonctionnel... sauf si on a besoin de ces perfs ou fonctionnalités. L'avantage principal ? Il n'y a qu'une seule convention de codage à connaître et à comprednre, que tu peux alors reprendre dans ton application : pas de dispute possible à ce sujet.

Dériver de QObject ? Seulement si ça peut être nécessaire : une classe qui ne sert que de stockage en a-t-elle réellement besoin ? Si elle a besoin de signaux, de slots ou d'autres, c'est obligatoire. Sinon, je n'en vois pas l'utilité. Il faut remarquer que la majoriét des classes de Qt en dépendent : ce n'est sûrement pas pour rien. Si c'était un inconvénient majeur, il y a fort à parier que, soit on n'hériterait pas aussi souvent de QObject, soit on optimiserait fortement QObject.

Concernant les pointeurs, regarde ceci : http://tcuvelier.developpez.com/qt/i...-intelligents/. Il n'y a pas que QPointer, loin de là.

Tu peux aussi regarder ce débat : http://www.developpez.net/forums/d79...-performances/
03/02/2010, 21h39
gbdivers

Merci pour les liens (j'avais déjà lu la page sur les différents pointeurs de Qt mais pas le débat sur les performances).

Pour les libs, on en utilise certaine qui sont trop spécifiques pour s'en passer (GSL, CGAL, libSVM...), ce qui pose des problèmes pour la portabilité. L'idéal serait d'utiliser aucune lib pour le core (sauf Qt) pour faciliter le travail des développeurs externes au projet (pour créer des plugins).

Pour les perfs, ça ne sera pas critique pour le core et l'IHM. Je crois que je vais utiliser les containers de Qt plutot que boost ou STL. Pour les algorithmes de traitements de données, on verra :)

Pour QObject, comme mes objets contiennent tous des méta-infos (paramètres des algorithmes pour le desgin pattern Stratégie, informations d'acquition pour les données), ça simplifiera le travail de les faire dériver de QObject (pour utiliser en autre les QProperty)

Au final, même si on gagne pas forcement en perfs, on gagnera en portabiltié et en maintenance.
03/02/2010, 23h37
yan

Salut

Citation:

Envoyé par gbdivers

- Actuellement, nous n'utilisons pas de pointeurs intelligents. Vaut-il mieux utiliser les QPointeurs (qui me semblent limités), boost ou STL ?

Depuis Qt 4.6, tu trouve à peu prés la même chose que boost. La S(T)L , il n'y as pour l'instant pas grand chose. Donc c'est surtout un choix personnelle.

Citation:

- Idem pour les conteneurs, vaut-il mieux utiliser la STL ou QVector et QMap ? Sont-ils plus lent ? plus rapide ? compatible ?

Ca depend du context. Si tu veut un code full Qt autant utiliser les conteneur Qt. Sinon, faut connaitre le context pour te répondre. En terme de rapidité, c'est équivalent. Une chose qui peut être interessant, les conteneur de Qt sont base sur le COW
http://qt.developpez.com/faq/?page=g...optimise-copie

Citation:

- Certain objets enregistrent des méta-informations à l'aide de classes "faites maison".

c'est à dire?

Citation:

QVariant et QProperty sont-ils robuste ? rapide ?

vue que c'est utilisé partout, oui.

Citation:

Quel est le coût en terme de rapidité ou de consommation mémoire ?

c'est à dire?

Citation:

Plus globalement, que pensez-vous d'une optique "tout Qt" pour un projet (c'est à dire utiliser QVector plutot que std:vector, QXml plutot que xerces, QPointer plutot que auto_ptr, etc.) ?

Ca depend du context. Mais un projet full Qt est viable. Cela permet aussi d'avoir un code homogène
04/02/2010, 10h08
gbdivers

Citation:

C'est à dire?

Je n'ai pas été très clair sur la question de la rapidité... Je vais "développez" :)

Je parle évidement de "rapidité" relative (par rapport à d'un librairie ou même d'écrire soi-même ses containers) et non de rapidité absolue. Comme tu le dis toi même, yan, c'est utilisé partout. Et partout veut dire polyvalence. Et polyvalence veut dire coût en terme de rapidité et de consommation mémoire.

Par exemple, la structure en arbre des QObject (accessible avec getParent et getChildren) utilise les QPointer qui utilisent eux-même le comptage de référence. Or, l'utilisation du comptage consomme du temps (incrémentation du pointeur, décrementation, vérification qu'il existe encore des pointeurs vers l'objet, etc.) et de la mémoire (pour le compteur).
Cependant, je suis garantie que mes objets seront détruit uniquement en passant par le parent (soit directement par l'utilisateur, soit parce que le parent est détruit). Je pourrais donc utiliser un auto_ptr pour lier le parent à l'enfant et des pointeurs standard dans tous les autres cas.

QProperty est également un système polyvalent et consomme donc peut être des ressources que ne sont pas nécessaire dans mon cas (je l'utilise en particulier avec le pattern Stratégie pour enregistrer les paramètres des fonctions appelées).

Lorsque l'on utilise ces objets polyvalents pour une IHM ou sur peu d'objet, le coût en mémoire et en temps est négligeable comparé à la maintenance. Le problème se pose quand il s'agit de les utiliser sur plusieurs dizaine de milliers d'objets : le coût n'est plus négligeable.

Malheureusement, je crois que la réponse ne pourra venir que de tests "grandeur nature"... Je passerai par l'approche Qt en premier. Et si le système est trop lent et peu réactif, je verrai pour l'optimisation hors Qt.

Merci de vos réponses.
04/02/2010, 14h46
3DArchi

Salut,
Plus ton projet sera truffé de Qt, plus il sera difficile de le faire migrer ou d'en extraire certaines parties pour du reuse. Il faut apprendre à doser. Il y a des parties qui seront nécessairement Qt mais pour d'autres la solution Qt n'est pas forcément adéquates (couche métier). Ne pas hésiter à utiliser le Principe d'Inversion de Dépendance.
Quand aux problèmes de perfs, substituer un conteneur à un autre ne devrait pas forcément être très laborieux si à la base ton code supporte la STL. Poses-toi la question de tuner ton conteneur au moment où tu auras mesuré que c'est bien lui qui te coûte en perf (et non ton algo ;)).
Bref, pour résumer, (et aussi pour avoir galérer sur des projets 100% MFC par expl), je suis de ceux qui pensent que les framework qui font tout, j'aime pô ! Et je préfère garder les parties qui le peuvent sans dépendance avec le framework (donc std::list plutôt que QList).
11/02/2010, 21h30
laumaya

Bonsoir,

Citation:

Envoyé par 3DArchi

Plus ton projet sera truffé de Qt, plus il sera difficile de le faire migrer ou d'en extraire certaines parties pour du reuse.

C'est pas faux mais :
- QT4 est bien plus qu'une librairie pour faire des interfaces utilisateur, et si tu veux développer pour du multi plateforme, ça facilite la vie !

- Si tu fais de l'open source, QT4 facilite aussi la vie des utilisateurs finaux... Et oui, pour compiler ton appli ou ta librairie, il faut juste QT4 et non pas un tas de lib à compiler :aie: Oui, c'est du vécue ;)

- Si tu utilise QT pour l'interface, le fait d'utiliser QT pour le cœur de ton application te permettra de gagner en performance -> Pas besoin de convertir les types d'autre lib en type QT et en plus tu gagnes en clarté.

- Pour ce qui est des perfs, je peux t'affirmer que l'API de QT est bien optimisée. J'utilise les containers (QList, QVector, QHash et QSet) de QT pour gérer des millions de polygons et des milliers d'objets. De plus pour parser des fichiers xml, txt, binaire de plusieurs centaine les classes de QT sont vraiment très performantes.

- J'utilise aussi la classe QProperty : Jamais eu de problèmes.

Pour conclure, je dirais que pour les container, QT est au moins aussi performant que la STL en étant plus facile à utiliser (API proche de JAVA)

Pour Info, j'ai commencé le C++ avec la stl et MFC. Maintenant j'utilise QT4 et je ne retournerais pour rien au monde à la STL et surtout pas au MFC pour mes projets.
http://www.glc-lib.net/forum/download/file.php?id=3
http://www.glc-player.net
11/02/2010, 21h35
yan

ton image, on dirais un ange pleureur dans docteur who
http://docteurwho.unblog.fr/files/20...pingangels.jpg
12/02/2010, 10h43
Niak74

(C'est pas Dr. House ?)
12/02/2010, 11h09
yan

Citation:

Envoyé par Niak74

(C'est pas Dr. House ?)

inculte :langue:
http://www.developpez.net/forums/d57...tv/doctor-who/
12/02/2010, 11h44
Niak74

(Le modèle 3D ressemble quand même très fortement au premier rôle de Dr House :langue: *part flooder*)
12/02/2010, 18h23
laumaya

:oops: J'ai oublié de précisser, le modèle provient de :
SCULPT4D
13/02/2010, 13h39
screetch

d'un côté cela lie fortement le coeur de la bibliothèque/du programme avec son interface graphique, avec tous les problèmes que cela peut engendrer : complications pour la portabilité, complications pour compiler le coeur du programme, forte influence de l'interface utilisateur sur le design du modèle.

d'un autre côté, si le modèle/coeur n'a pas lieu d'etre sans l'interface utilisateur alors ce problème n'en est pas un.

je suis pour utiliser les bibliothèques de haut niveau seulement lorsqu'on travaille a un haut niveau; par exemple, une bibliothèque de chargement/affichage de mesh ne devrait selon moi pas être ecrite avec des bibliothèques de haut niveau; tandis que son interface graphique a tout a fait interet a utiliser les composants très haut niveau
13/02/2010, 16h25
yan

Citation:

Envoyé par screetch

d'un côté cela lie fortement le coeur de la bibliothèque/du programme avec son interface graphique, avec tous les problèmes que cela peut engendrer : complications pour la portabilité, complications pour compiler le coeur du programme, forte influence de l'interface utilisateur sur le design du modèle.

d'un autre côté, si le modèle/coeur n'a pas lieu d'etre sans l'interface utilisateur alors ce problème n'en est pas un.

je suis pour utiliser les bibliothèques de haut niveau seulement lorsqu'on travaille a un haut niveau; par exemple, une bibliothèque de chargement/affichage de mesh ne devrait selon moi pas être ecrite avec des bibliothèques de haut niveau; tandis que son interface graphique a tout a fait interet a utiliser les composants très haut niveau

c'est assez souvent ce que je fait.
Qt uniquement la ou il faut.

Mais dernièrement, j'ai développer un client mail en Qt pour un client. Pour minimiser les dépendances, on as tous fait avec Qt, même le coeur (sgbd, sockect, ...).
Faire du full Qt est viable. Nous c'était une des contraintes. Qt est assez puissant et diversifié pour être utilisé partout. C'est équivalent (pas sur tous les points) à un framework .net.

Après, tous dépend de ce que l'on veut faire.
13/02/2010, 16h29
3DArchi

Je crois comprendre dans l'argumentaire de screetch une critique qui me semble pertinente : à mettre Qt (ou un autre framework) partout et là où on en aurait pas forcément besoin, on finit aussi par avoir une architecture qui est construite en fonction de Qt et non plus du problème que l'on souhaite résoudre. Je partage cette crainte.
13/02/2010, 16h47
yan

Citation:

Envoyé par 3DArchi

Je crois comprendre dans l'argumentaire de screetch une critique qui me semble pertinente : à mettre Qt (ou un autre framework) partout et là où on en aurait pas forcément besoin, on finit aussi par avoir une architecture qui est construite en fonction de Qt et non plus du problème que l'on souhaite résoudre. Je partage cette crainte.

je suis d'accord.
Mais ce que je veux dire, que c'est crainte n'est pas forcement justifier
Qu'es ce qui est le plus intéressant?
* dépendre s'une seul lib qui répond à tous mes besion (multiplateforme, xml, sgbd, ...)
* dépendre de plusieurs petit lib qui groupé vont répondre à mes besoin, mais chaqu'une à son interface, pose des problème de conpatibilité en multi-plateforme,...

Si c'est choix, prendre Qt partout ne pose aucun problème. Et pour les fane de la STL, c'est compatible. Mais ce genre de décision doit être réfléchie.

Le problème en C++, contrairement à java ou .net, c'est que par défaut, la S(T)L n'est pas complète. Il faut trés souvent utiliser une ou plusieur lib externe.
13/02/2010, 16h58
3DArchi

Il y a une autre idée qui est de d'abord designer en fonction du problème et ensuite utiliser Qt pour le résoudre. Et non pas designer en fonction de Qt parce qu'on va l'utiliser pour résoudre le problème. Sinon, le fait que C++ n'ai pas en natif un framework, c'est aussi ce qui fait qu'on le retrouve dans beaucoup de plateformes, pc, mais aussi embarqué.
13/02/2010, 17h40
laumaya

Citation:

Envoyé par screetch

d'un côté cela lie fortement le coeur de la bibliothèque/du programme avec son interface graphique, avec tous les problèmes que cela peut engendrer : complications pour la portabilité, complications pour compiler le coeur du programme, forte influence de l'interface utilisateur sur le design du modèle.

d'un autre côté, si le modèle/coeur n'a pas lieu d'etre sans l'interface utilisateur alors ce problème n'en est pas un.

je suis pour utiliser les bibliothèques de haut niveau seulement lorsqu'on travaille a un haut niveau; par exemple, une bibliothèque de chargement/affichage de mesh ne devrait selon moi pas être ecrite avec des bibliothèques de haut niveau; tandis que son interface graphique a tout a fait interet a utiliser les composants très haut niveau

Je ne suis complétement d'accord. je m'explique :
Ce n'est pas par ce qu'on utilise QT pour le coeur d'une bibliothèque ou d'un programme qu'on le lie à une interface graphique. QT est très riche et peut être comparé à l'API de JAVA il est donc tout à fait possible d'utiliser des classes de QT qui n'ont rien à voir avec l'interface graphique.

Concernant l'utilisation d'une bibliothèque de haut niveaux pour charger et afficher des meshs je suis encore moins d'accord avec screetch. Pour étayer mon point de vu, je vais m'appuyer sur ce que je connais : GLC_Lib qui utilise QT et qui à besoins des fonctionnalités suivantes :
- Parser des fichier xml (Collada 3dxml)
- Lire plusieurs formats d'image (les mesh ont bien souvent des textures)
- Transformer ces images en texture Opengl
- Ouvrir des archives Zip (3dxml)
- Compresser et décompresser des données (Fichier Binaire serialisés)
- Utilisé des structures de haut niveau pour transformer les structures de données lues (Table de Hashage, Set, ...)
- Charger des extensions OpenGL quelque soit le système d'exploitation
....
:mouarf:
13/02/2010, 18h24
yan

Citation:

Envoyé par 3DArchi

Il y a une autre idée qui est de d'abord designer en fonction du problème et ensuite utiliser Qt pour le résoudre.

+1000

Citation:

Et non pas designer en fonction de Qt parce qu'on va l'utiliser pour résoudre le problème.

:koi: comment cela?

Citation:

Envoyé par 3DArchi

Sinon, le fait que C++ n'ai pas en natif un framework, c'est aussi ce qui fait qu'on le retrouve dans beaucoup de plateformes, pc, mais aussi embarqué.

Et c'est la où Qt est intéressant. Ils ont une très grande liste de compilateur/plateforme supporté. Même assez vieux.
Qt n'est plus compatible vc6 que depuis Qt 4.5!!
13/02/2010, 23h36
screetch

mon avis se résume ainsi : quand on a un marteau on a tendance a voir tous les problèmes comme des clous (Abraham Maslow)
il est important de trouver l'outil idéal pour son problème.

or, Qt reste une bibliothèque d'interface graphique, bien que polyvalente.

son utilisation peut donc résoudre un tas de problemes différent bien sur; mais, a force de voir en Qt la solution idéale on a tendance a prendre Qt comme l'outil qui résout tout (ce qui est un enorme défaut)

et je dirai de plus que la plupart des gens de ce forum font de même en pensant que chaque problème (a tort) est résolu par du code C++. Ca peut être vrai mais c'est pas le plus performant. (je suis le premier a tomber dans cette catégorie, en toute honnêteté. c'est un problème tout a fait humain. s'en tirer relève du vrai génie et si tu y arrives, alors bravo :) )
13/02/2010, 23h39
screetch

Citation:

Envoyé par laumaya

Je ne suis complétement d'accord. je m'explique :
Ce n'est pas par ce qu'on utilise QT pour le coeur d'une bibliothèque ou d'un programme qu'on le lie à une interface graphique.

GTK a grosso modo les mêmes fonctionnalités. Si tu utilises des Qlist pour ton mesh d'un seul coup l'interface graphique devient "forcément" en Qt, et tu te prives de la possibilité d'utiliser GTK. Or, rien ne me dit qu'un mesh doive utiliser une interface Qt pour etre édité. C'est pour moi le contraire de ce que tu as dit : utiliser des Qlist dans une bibliothèque bas niveau c'est conduire un autre développeur a utiliser Qt sur une bibliothèque haut niveau.
14/02/2010, 10h53
Invité

Citation:

Envoyé par screetch

GTK a grosso modo les mêmes fonctionnalités.

Tous les framework d'interface, en fait... Tous ceux que je connais (perso j'utilise Borland, je regarde Qt de loin) ont tendance à se vouloir des "sur langage" du C++. Avec, on peut développer presque sans connaitre le C++, quasiment tout est déjà mâché, et ça gagne beaucoup de temps.

Sur de petits projets (disons destinés à durer deux ou trois ans) avec beaucoup d'IHM, et peu de valeur ajoutée métier (genre la couche métier c'est une base de données qu'on requête, et le soft présente les résultats et cache les détails du SQL), c'est la bonne solution. Il faut prendre le framework que le dev principal connait, et exiger des autres qu'ils le connaissent ou l'apprennent... Au total, ce sont plus des projets en Qt que des projets en C++, mais ce n'est pas un problème, ca va marcher, ca va se développer vite, c'est parfait.

Sur des projets avec beaucoup de C++ et très peu d'IHM, le framework doit être aussi minimisé que possible. Là le tout Qt (ou n'importe quel autre framework) est une aberration. On écrit un moteur en C++, et on branche ca sur une interface. Si l'interface est en Qt, il faut essayer d'éviter tout les Qt-isme qui peuvent l'être.

La vraie difficulté, c'est la situation intermédiaire: une IHM importante, et pas mal de calcul métier, dans une appli qui doit durer une dizaine d'années et au delà. A mon avis, une parfaite isolation IHM-moteur est à peu près impossible. Tout ou tard, la jolie frontière qu'on a bâtie entre les deux deviendra poreuse et floue. L'argument de la vitesse (des "fonctions Q" vs la STL) ne me parait pas recevable: en général, en sachant bien utiliser l'un ou l'autre on arrive toujours à compenser). Pour moi, le choix du tout framework présente un avantage : il limite le nombre de librairies que les developpeurs (présents ou futurs) doivent maîtriser. Si on n'a que Qt, alors on n'a plus besoin d'apprendre boost, les détails de la STL (la grande majorité des devs connaissent mal la STL), etc... Le revers de la médaille, c'est que si dans 5 ans, Qt passe de mode (ca arrivera forcément), il sera plus difficile d'interesser les nouveaux recrutés à cette "techno du passé".

Du coup, etre tout Qt, ca signifie dépendre pas mal des spécialistes Qt de son entreprise. Mais c'est vrai de tout framework.

Le seul intérêt de conserver un peu de "non framework" dans le projet, c'est si on décide un jour d'en utiliser un autre, pour un autre projet, par exemple. Si tu veux lancer un projet GTK, tout ton joli code Qt est inutilisable. Les parties STL le seront...

Vis à vis de Borland (mon framework), ma stratégie est la suivante
- toujours aller dans le sens du framework (lutter contre, c'est idiot)
- là ou une solution équivalente mais standard existe (STL ou autre) toujours la préférer à la solution Borland
- sauf si cette solution est plus complexe à implémenter, et à débugger

Sur la critique de screetch, je suis assez d'accord que les applis "héritent" du framework qu'elles utilisent, mais je ne crois pas qu'il soit possible de faire autrement... Tenter l'inverse, c'est souvent "lutter contre" le framework, et passer son temps à se battre contre les outils qui sont censés nous simplifier la vie.

Francois
14/02/2010, 11h08
yan

Citation:

Envoyé par screetch

GTK a grosso modo les mêmes fonctionnalités. Si tu utilises des Qlist pour ton mesh d'un seul coup l'interface graphique devient "forcément" en Qt, et tu te prives de la possibilité d'utiliser GTK.

Qt est découpé en module (et dll au maximum indépendante). Tu peut sans trop problème utiliser le core, le network, le xml ou la partie sgbd sans la partie ihm. Et faire ton ihm avec gtk ou autre. Tout comme tu peut utiliser glib sans gtk+.
De plus y as des travaux pour les rendre compatible
http://gitorious.org/gqt

C'est pour cela que Qt est soit
* QCoreApplication : appli sans ihm
* QApplication : appli avec ihm.

Pour faire un équivalent avec GTK :
QtCore <=> Glib
QtGui <=> GTK+

Citation:

Envoyé par screetch

Or, rien ne me dit qu'un mesh doive utiliser une interface Qt pour etre édité. C'est pour moi le contraire de ce que tu as dit : utiliser des Qlist dans une bibliothèque bas niveau c'est conduire un autre développeur a utiliser Qt sur une bibliothèque haut niveau.

Pour moi c'est un choix technologique. Faut savoir faire le pour et le contre.

Citation:

mais, a force de voir en Qt la solution idéale on a tendance a prendre Qt comme l'outil qui résout tout (ce qui est un enorme défaut)

et je dirai de plus que la plupart des gens de ce forum font de même en pensant que chaque problème (a tort) est résolu par du code C++. Ca peut être vrai mais c'est pas le plus performant. (je suis le premier a tomber dans cette catégorie, en toute honnêteté. c'est un problème tout a fait humain. s'en tirer relève du vrai génie et si tu y arrives, alors bravo )

mais je suis tous à fait d'accord avec ceci, Qt n'est pas LA solution. S'en est une parmi d'autre et pas pour tous.
Je pense que l'on as tendance à vouloir utiliser ce que l'on maitrise le plus. Mais faut être ouvert technologiquement. Dernièrement je devais faire un petit server rest locale. Me disant que c'est simple, j'ai commencé en Qt. Et après une journée et vue à quel point faut réinventé la roue,j'ai laissé tombé pour du C#.
Et la en moins de 20 lignes j'avais mon server 1000x plus puissant que ce que j'avais fait et sans prise de tête. Et je n'ai rien regrette. Surtout quand j'ai du exploiter en plus des objets COM ou tout est grandement simplifié en .Net.
14/02/2010, 11h34
yan

Citation:

Envoyé par fcharton

Tous les framework d'interface, en fait... Tous ceux que je connais (perso j'utilise Borland, je regarde Qt de loin) ont tendance à se vouloir des "sur langage" du C++. Avec, on peut développer presque sans connaitre le C++, quasiment tout est déjà mâché, et ça gagne beaucoup de temps.

Qt c'est du C++, sinon il ne supporterai pas autant de compilateur; Borland c'est surtout un compilateur C++ avec son framework.
(enfin il me semble)

Citation:

Si on n'a que Qt, alors on n'a plus besoin d'apprendre boost, les détails de la STL (la grande majorité des devs connaissent mal la STL), etc...

Ça c'est une remarque faite à Qt que j'arrive pas à comprendre. En quoi faire du Qt t'empêche d'utiliser boost ou autre? A chaque fois j'ai l'impression que les gens pensent que Qt est un langage... c'est du C++, ce que génère moc et uic c'est du C++(que tu n'as pas envie et l'intérêt de l'écrie à la main). Ce qui compile ton code est un compilateur C++. Rien n'oblige de l'utiliser partout. Sur un projet, j'ai utiliser Qt pour xpath, boost pour ses quaternions, matrices et smart_ptr et la stl pour le reste.
Je n'ai pas eu de problème.

Citation:

Envoyé par fcharton

Le seul intérêt de conserver un peu de "non framework" dans le projet, c'est si on décide un jour d'en utiliser un autre, pour un autre projet, par exemple. Si tu veux lancer un projet GTK, tout ton joli code Qt est inutilisable. Les parties STL le seront...

C'est la même chose pour toute lib (boost, poco, ...). C'est un points qu'il faut prendre en compte. Si on veut la changer cela aura un coup.

Je trouve qu'il est de bonne pratique de faire (quand c'est pertinent) ses propres classes pour interfacer la lib et ainsi pouvoir en utiliser une autre si besoin. Bon d'accord avec des framework type Qt c'est pas toujours possible.
14/02/2010, 12h19
Invité

Citation:

Envoyé par yan

Qt c'est du C++, sinon il ne supporterai pas autant de compilateur; Borland c'est surtout un compilateur C++ avec son framework.

En fait, le framework Borland c'est du Delphi, mais qui s'interface, via l'EDI et le compilateur, avec du C++.

Mais dans un cas comme dans l'autre, on peut utiliser les composants de haut niveau comme une sorte de "sur langage", c'est à dire qu'on assemble des briques assez grosses, sans presque jamais faire de C++.

Le C++ de base, c'est un peu du mecano, t'as des barres, des écrous, des boulons, un moteur. Les frameworks, c'est plutot des legos technic, avec des grosses pieces spécialement formées pour les besoins de la cause.

Citation:

Envoyé par yan

Ça c'est une remarque faite à Qt que j'arrive pas à comprendre. En quoi faire du Qt t'empêche d'utiliser boost ou autre? A chaque fois j'ai l'impression que les gens pensent que Qt est un langage...

Rien n'empêche de le faire, sauf le temps disponible. En général, sur un projet, tu es toujours en délais contraints, donc tu vas au plus vite. Par ailleurs, il vaut mieux bien maitriser une librairie que d'en connaitre vaguement 5. Et on parle là de choses (Boost, Qt) qui évoluent assez vite. La question se pose donc, quand tu décides de te former, de savoir s'il vaut mieux approfondir le framework que tu utilises, ou essayer d'en apprendre un autre au cas où (ou te former sur un bout de boost que tu ne connais pas)...

Si tu travailles avec une équipe, la dernière chose que tu veux, c'est que tes développeurs passent la moitié de leur temps à lire des manuels, pour se faire une culture générale ou se mettre à jour sur une demi douzaine de technologies. (Je te garantis que la majorité ne le fera pas sur son temps libre...)

Tu ne veux pas non plus que chacun écrive dans son jargon, parce que le code va vite devenir inmaintenable, et que les petites incompatibilités entre librairies vont faire perdre un temps fou (ne serait ce qu'en palabres sur qui a la meilleure...)

Au total, tu peux bien sur tout utiliser, Qt, GTK+, Boost, et d'autres, mais sur un projet, tu préfères souvent avoir un petit nombre d'outils communs, que tout le monde maitrise, avec parfois un ou deux spécialistes qui gèrent les cas tordus. Tu te retrouves avec un code plus maintenable, moins dépendant de ceux qui l'ont écrit, et souvent plus concis.

Et du coup, quand tu as un framework qui te propose pas mal de choses, la question de se limiter à ce seul framework est assez légitime, enfin je crois.

Citation:

Envoyé par yan

Je trouve qu'il est de bonne pratique de faire (quand c'est pertinent) ses propres classes pour interfacer la lib et ainsi pouvoir en utiliser une autre si besoin. Bon d'accord avec des framework type Qt c'est pas toujours possible.

Avec les framework d'IHM, je doute que ce soit jamais possible... Avec d'autres libs ca l'est parfois, mais d'expérience, on écrit souvent ces classes d'interface, en se disant "comme ca on pourra", et le jour ou on doit le faire, ben on se rend compte qu'on avait oublié des choses, forcément parce qu'on ne connaissait qu'une lib, et pas la "nouvelle" qui ne marche justement pas avec la classe, etc...

Francois
14/02/2010, 19h36
yan

Citation:

Envoyé par fcharton

Rien n'empêche de le faire, sauf le temps disponible. En général, sur un projet, tu es toujours en délais contraints, donc tu vas au plus vite. Par ailleurs, il vaut mieux bien maitriser une librairie que d'en connaitre vaguement 5. Et on parle là de choses (Boost, Qt) qui évoluent assez vite. La question se pose donc, quand tu décides de te former, de savoir s'il vaut mieux approfondir le framework que tu utilises, ou essayer d'en apprendre un autre au cas où (ou te former sur un bout de boost que tu ne connais pas)...

Si tu travailles avec une équipe, la dernière chose que tu veux, c'est que tes développeurs passent la moitié de leur temps à lire des manuels, pour se faire une culture générale ou se mettre à jour sur une demi douzaine de technologies. (Je te garantis que la majorité ne le fera pas sur son temps libre...)

Tu ne veux pas non plus que chacun écrive dans son jargon, parce que le code va vite devenir inmaintenable, et que les petites incompatibilités entre librairies vont faire perdre un temps fou (ne serait ce qu'en palabres sur qui a la meilleure...)

Au total, tu peux bien sur tout utiliser, Qt, GTK+, Boost, et d'autres, mais sur un projet, tu préfères souvent avoir un petit nombre d'outils communs, que tout le monde maitrise, avec parfois un ou deux spécialistes qui gèrent les cas tordus. Tu te retrouves avec un code plus maintenable, moins dépendant de ceux qui l'ont écrit, et souvent plus concis.

Et du coup, quand tu as un framework qui te propose pas mal de choses, la question de se limiter à ce seul framework est assez légitime, enfin je crois.

je trouve que tu viens de donner une des meilleur réponse au débat.