Journal Question QT

Posté par  .
Étiquettes : aucune
0
15
avr.
2004
Pour ceux qui ont l'habitude de développer sous QT...

Pour les objets non graphiques disponibles aussi dans les librairies standards (fichiers, chaines de caractères, etc...), vous utilisez plutot les objets QT ou ceux des autres biblios ?

  • # Re: Question QT

    Posté par  (site web personnel) . Évalué à 1.

    Autant utiliser ceux de QT s'ils existent.
    Les outils de QT sont assez complet, et couvrent la majorités des besoins.

    Ton application est déjà liée à QT, donc niveau performance ça devrais être mieux que de dépendre d'une autre bibliothèque.

    • [^] # Re: Question QT

      Posté par  . Évalué à 1.

      mais la librairie standard c++ on en dépend pas de toutes façons ?

      • [^] # Re: Question QT

        Posté par  . Évalué à 1.

        Qt est plus vieux que la stdc++, donc on est pas forcé d'en dépendre. Cependant dans les dernières versions de Qt il y a une option à la compilation qui permet d'avoir une compatibilité entre les objets stdc++ et Qt (par ex string et QString)... est ce que dans ce cas c'est la stdc++ qui est utilisée? peut être mais bon si on en veut pas on peut s'en passer!

        • [^] # Re: Question QT

          Posté par  . Évalué à 1.

          Ça ça m'intéresse, je n'arrive pas à utiliser cette fonctionalité. Par exemple impossible de compiler ce bout de code :

          #include <qstring.h>
          #include
          #include

          using namespace std;

          int main() {
          string my_std_string("bar");
          QString my_qt_string(my_std_string);
          cout << my_qt_string << endl;
          }

          J'ai essayé de compiler Qt avec le flag -stl au ./configure, mais lorsque je lance le make pour compiler, je vois des -DQT_NO_STL à chaque appel à g++.

  • # Re: Question QT

    Posté par  . Évalué à 1.

    Moi jai un peu de scrupule a linker qt, qui est tout de meme bien gros, si je n'utilise pas la partie ui, ou au moin une grosse majorité des fonctionnalitées.
    Dun autre coté, sous linux cest tout de meme le plus complet des framework c++, voir le seul.

    Si cest juste pour les fichiers ou les strings, je prefere autant utiliser la stl.

    • [^] # Re: Question QT

      Posté par  . Évalué à 1.

      Bah en fait c'est le contraire. J'ai besoin de l'ui mais je me demande si pour ce qui n'est pas ui, j'utilise la stl ou les objets qt

      • [^] # Re: Question QT

        Posté par  . Évalué à 1.

        si tu utilises deja l'ui, autant continuer avec qt, enfin cest mon avis, les classes qt sont en général plus complète, comme par exemple la gestion de l'unicode pour QString, la gestion des thread, et toutes les classes dont tu aurais besoin qui implementent des signals/slots... et surtout la doc (assistant) que je trouve mieu foutu que toutes les docs pour la stl que jai pu trouver sur le net

  • # Re: Question QT

    Posté par  . Évalué à 1.

    Ça dépend. Si je veux du portable (windows, mac, unix), je fais "confiance" à Qt et j'utilise du Qt.

    • [^] # Re: Question QT

      Posté par  . Évalué à 1.

      y a aussi TinyQT, un dérivé de QT sans les lib graphiques si ca t'intéresse

      • [^] # Re: Question QT

        Posté par  . Évalué à 1.

        Pour la compatibilté, la stl est mieux justement. Pour ce qui est de l'ui j'utilise bien entendu qt, mais si je dois faire des classes qui ne sont pas directement liée à l'ihm, j'essaie de me passer de qt. Comme ça, tu gardes la possibilité de faire une appli wxwindow par exemple et de réutiliser ta classe sans aucune modification. Car si il y a quelque temps la stl n'était pas très bien implémentée sur tous les compilos, maintenant ce n'est plus vraiment le cas, et du coup la stl est plus portable que qt. Maintenant si en utilisant qt tu peux gagner beacoup de temps de dev (gestion fichier xml par exemple) alors autant en profiter. Mais pour ce qui est des chaines de caractère, je préfére std::string pour les collections, je préfére les std::vector, std::map... pour les fichiers je préfère std::ifstream.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.