Qt contre le monde : Qt pour tout, ou un usage plus raisonné doit-il prévaloir ?

Membre confirmé

Le 11/02/2010 à 21:30

Bonsoir,

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

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

1

0

yan

Rédacteur

Le 11/02/2010 à 21:35

ton image, on dirais un ange pleureur dans docteur who

1

0

Niak74

Membre averti

Le 12/02/2010 à 10:43

(C'est pas Dr. House ?)

1

0

yan

Rédacteur

Le 12/02/2010 à 11:09

Envoyé par Niak74

(C'est pas Dr. House ?)

inculte

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

1

0

dourouc05

Responsable Qt & Livres

Le 03/02/2010 à 19:47

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/

0

gbdivers

Inactif

Le 03/02/2010 à 21:39

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.

0

yan

Rédacteur

Le 03/02/2010 à 23:37

Salut

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.

- 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

0

gbdivers

Inactif

Le 04/02/2010 à 10:08

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.

0

3DArchi

Rédacteur

Le 04/02/2010 à 14:46

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

0

Niak74

Membre averti

Le 12/02/2010 à 11:44

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

*part flooder*)

0

Identifiez-vous

Créer un compte

Qt contre le monde : Qt pour tout, ou

Un usage plus raisonné doit-il prévaloir ?

Identifiant
Mot de passe

Mot de passe oublié ?

Identifiez-vous

Créer un compte

Qt contre le monde : Qt pour tout, ou Un usage plus raisonné doit-il prévaloir ?

Qt contre le monde : Qt pour tout, ou

Un usage plus raisonné doit-il prévaloir ?