Discussion :

[gbdivers]

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

[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/

[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.

[yan]

Salut

- 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.

- 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

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

c'est à dire?

QVariant et QProperty sont-ils robuste ? rapide ?

vue que c'est utilisé partout, oui.

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

c'est à dire?

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

[gbdivers]

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.

[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).

[laumaya]

Bonsoir,

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 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-player.net

[yan]

ton image, on dirais un ange pleureur dans docteur who

[Niak74]

(C'est pas Dr. House ?)

[yan]

(C'est pas Dr. House ?)

inculte
http://www.developpez.net/forums/d57...tv/doctor-who/

[Niak74]

(Le modèle 3D ressemble quand même très fortement au premier rôle de Dr House *part flooder*)

[laumaya]

J'ai oublié de précisser, le modèle provient de :
SCULPT4D

[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

[yan]

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.

[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.

[yan]

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.

[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é.

[laumaya]

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
....

[yan]

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

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

comment cela?

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!!

[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 )