IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Qt Discussion :

Qt contre le monde : Qt pour tout, ou un usage plus raisonné ? [Débat]


Sujet :

Qt

  1. #1
    Inactif  


    Homme Profil pro
    Inscrit en
    Novembre 2008
    Messages
    5 288
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Secteur : Santé

    Informations forums :
    Inscription : Novembre 2008
    Messages : 5 288
    Points : 15 617
    Points
    15 617
    Par défaut 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

  2. #2
    Responsable Qt & Livres


    Avatar de dourouc05
    Homme Profil pro
    Ingénieur de recherche
    Inscrit en
    Août 2008
    Messages
    26 680
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur de recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2008
    Messages : 26 680
    Points : 188 772
    Points
    188 772
    Par défaut
    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/

  3. #3
    Inactif  


    Homme Profil pro
    Inscrit en
    Novembre 2008
    Messages
    5 288
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Secteur : Santé

    Informations forums :
    Inscription : Novembre 2008
    Messages : 5 288
    Points : 15 617
    Points
    15 617
    Par défaut
    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.

  4. #4
    yan
    yan est déconnecté
    Rédacteur
    Avatar de yan
    Homme Profil pro
    Ingénieur expert
    Inscrit en
    Mars 2004
    Messages
    10 033
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur expert
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2004
    Messages : 10 033
    Points : 13 968
    Points
    13 968
    Par défaut
    Salut

    Citation Envoyé par gbdivers Voir le message
    - 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

  5. #5
    Inactif  


    Homme Profil pro
    Inscrit en
    Novembre 2008
    Messages
    5 288
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Secteur : Santé

    Informations forums :
    Inscription : Novembre 2008
    Messages : 5 288
    Points : 15 617
    Points
    15 617
    Par défaut
    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.

  6. #6
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Points : 13 017
    Points
    13 017
    Par défaut
    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).

  7. #7
    Membre confirmé
    Avatar de laumaya
    Homme Profil pro
    Développeur multimédia
    Inscrit en
    Août 2008
    Messages
    82
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur multimédia

    Informations forums :
    Inscription : Août 2008
    Messages : 82
    Points : 456
    Points
    456
    Par défaut
    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 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

  8. #8
    yan
    yan est déconnecté
    Rédacteur
    Avatar de yan
    Homme Profil pro
    Ingénieur expert
    Inscrit en
    Mars 2004
    Messages
    10 033
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur expert
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2004
    Messages : 10 033
    Points : 13 968
    Points
    13 968
    Par défaut
    ton image, on dirais un ange pleureur dans docteur who

  9. #9
    Membre averti
    Avatar de Niak74
    Profil pro
    Inscrit en
    Juin 2007
    Messages
    271
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations forums :
    Inscription : Juin 2007
    Messages : 271
    Points : 333
    Points
    333
    Par défaut
    (C'est pas Dr. House ?)

  10. #10
    yan
    yan est déconnecté
    Rédacteur
    Avatar de yan
    Homme Profil pro
    Ingénieur expert
    Inscrit en
    Mars 2004
    Messages
    10 033
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur expert
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2004
    Messages : 10 033
    Points : 13 968
    Points
    13 968
    Par défaut
    Citation Envoyé par Niak74 Voir le message
    (C'est pas Dr. House ?)
    inculte
    http://www.developpez.net/forums/d57...tv/doctor-who/

  11. #11
    Membre averti
    Avatar de Niak74
    Profil pro
    Inscrit en
    Juin 2007
    Messages
    271
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations forums :
    Inscription : Juin 2007
    Messages : 271
    Points : 333
    Points
    333
    Par défaut
    (Le modèle 3D ressemble quand même très fortement au premier rôle de Dr House *part flooder*)

  12. #12
    Membre confirmé
    Avatar de laumaya
    Homme Profil pro
    Développeur multimédia
    Inscrit en
    Août 2008
    Messages
    82
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur multimédia

    Informations forums :
    Inscription : Août 2008
    Messages : 82
    Points : 456
    Points
    456
    Par défaut
    J'ai oublié de précisser, le modèle provient de :
    SCULPT4D

  13. #13
    screetch
    Invité(e)
    Par défaut
    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

  14. #14
    yan
    yan est déconnecté
    Rédacteur
    Avatar de yan
    Homme Profil pro
    Ingénieur expert
    Inscrit en
    Mars 2004
    Messages
    10 033
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur expert
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2004
    Messages : 10 033
    Points : 13 968
    Points
    13 968
    Par défaut
    Citation Envoyé par screetch Voir le message
    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.

  15. #15
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Points : 13 017
    Points
    13 017
    Par défaut
    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.

  16. #16
    yan
    yan est déconnecté
    Rédacteur
    Avatar de yan
    Homme Profil pro
    Ingénieur expert
    Inscrit en
    Mars 2004
    Messages
    10 033
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur expert
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2004
    Messages : 10 033
    Points : 13 968
    Points
    13 968
    Par défaut
    Citation Envoyé par 3DArchi Voir le message
    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.

  17. #17
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Points : 13 017
    Points
    13 017
    Par défaut
    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é.

  18. #18
    Membre confirmé
    Avatar de laumaya
    Homme Profil pro
    Développeur multimédia
    Inscrit en
    Août 2008
    Messages
    82
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur multimédia

    Informations forums :
    Inscription : Août 2008
    Messages : 82
    Points : 456
    Points
    456
    Par défaut
    Citation Envoyé par screetch Voir le message
    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
    ....

  19. #19
    yan
    yan est déconnecté
    Rédacteur
    Avatar de yan
    Homme Profil pro
    Ingénieur expert
    Inscrit en
    Mars 2004
    Messages
    10 033
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur expert
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2004
    Messages : 10 033
    Points : 13 968
    Points
    13 968
    Par défaut
    Citation Envoyé par 3DArchi Voir le message
    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?

    Citation Envoyé par 3DArchi Voir le message
    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!!

  20. #20
    screetch
    Invité(e)
    Par défaut
    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 )

Discussions similaires

  1. Calendrier Outlook pour tout le monde
    Par Yepazix dans le forum SharePoint
    Réponses: 0
    Dernier message: 09/08/2007, 00h32
  2. Base en réseau pas disponible pour tout le monde
    Par Boubas1 dans le forum Sécurité
    Réponses: 1
    Dernier message: 26/06/2007, 20h50
  3. Réponses: 1
    Dernier message: 24/05/2006, 20h47
  4. [jdbc] pour tout le monde ?
    Par if_zen dans le forum JDBC
    Réponses: 5
    Dernier message: 21/04/2006, 14h24

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo