Discussion :

[Davidbrcz]

Bonjour à tous.
Je me pose une petite question.
Je vais sans doute recoder avec Qt un petit logiciel qui permet de changer le fond d'écran automatiquement.
Faut t'il que j'utilise Qt pour me fournir les classes de vecteurs,strings ... ou faut il que j'utilise ceux de la STL ?

En effet, utiliser ceux de Qt m'apporte des avantages non négligable mais cela revient a violer le DIP.

Utiliser ceux de la STL me permet d'avoir un code compilable même si je change de lib pour ma GUI et je ne viole pas le DIP mais je me bouffe des classes moyennement concus.

Alors, votre avis ?

Merci.

[kacedda]

ceux de la STL /**/ classes moyennement concus.

Juste pour participer , pourquoi tu dis ca, a mon avis(pas expert) elles sont bien celle de la STL. Et en plus comme tu dis c'est plus portable. Celles de Qt ont plus de fonctions?

Et sinon c'est quoi un DIP?

[Luc Hermitte]

Le COW peut avoir un prix sous certaines circonstances, ou présenter un avantage en l'absence de sémantique de déplacement selon les écritures.

Perso je préfère avoir mes noyaux indépendants de tout framework. Si maintenant tu sais que tu pars sur du Qt à tout jamais et que tanpis pour les vecteurs du C++0x ... pourquoi pas.
Un truc qui se fait, c'est de ne jamais écrire en dur que les types de tes classes sont des std::vector<> ou autre. Passe par des typedefs à la place. Ceci dit, cela ne sera valable que si les interfaces de manipulations sont identiques.

[Davidbrcz]

Juste pour participer , pourquoi tu dis ca, a mon avis(pas expert) elles sont bien celle de la STL. Et en plus comme tu dis c'est plus portable. Celles de Qt ont plus de fonctions?

Et sinon c'est quoi un DIP?

Disons que certaines classe de la STL gene std::string sont un peu (beaucoup) des classe foure-tout assez mal foutu (AMHA).
Et puis quand tu compare avec celle de Qt (http://qt.developpez.com/doc/4.3/qstring-members/) ya pas photo

Sinon : Principe d’inversion des dépendances <=> Dependency Inversion Principle (DIP)

Le COW peut avoir un prix sous certaines circonstances, ou présenter un avantage en l'absence de sémantique de déplacement selon les écritures.

COW ?

Perso je préfère avoir mes noyaux indépendants de tout framework. Si maintenant tu sais que tu pars sur du Qt à tout jamais et que tanpis pour les vecteurs du C++0x ... pourquoi pas.

Disons que quand je code des truc qui sont capable de me reservir,moi aussi.
Mais là,cette application aur un rôle bien précis et je ne me vois pas réutiliser son code plus tard.

Et puis une application n'est jamais figé.La première version de celle ci était avec wxWidgets. La V2 sera avec Qt.La V3 sera peut être avec C++Ox .
Alors dire que je part dans Qt pour tout jamais c'est s'aventurer beaucoup trop loin.

Un truc qui se fait, c'est de ne jamais écrire en dur que les types de tes classes sont des std::vector<> ou autre. Passe par des typedefs à la place. Ceci dit, cela ne sera valable que si les interfaces de manipulations sont identiques.

><
Je faisait malheursement le contraire quand j'ai codé cette appli.

[Luc Hermitte]

COW ?

Copy On Write. On en a déjà parlé ici (en rapport avec Qt en particulier). Et tu trouveras des choses à ce sujet sur GOTW (Guru Of The Week -> www.gotw.ca/gotw/)

Je faisait malheursement le contraire quand j'ai codé cette appli.

Cela devrait te permettre de switcher rapidement entre le vecteur standard et celui de Qt (tant que tu n'utilises pas les spécificités d'itération de Qt)[1], mais peut-être pas pour les chaînes si justement tu recherches une dont l'interface est mieux foutue.

[1] quoique je j'ai un doute, car j'ai l'impression (je peux me tromper) que le COW pousse au passage par copie, plutôt que par référence constante.

[Davidbrcz]

Copy On Write. On en a déjà parlé ici (en rapport avec Qt en particulier). Et tu trouveras des choses à ce sujet sur GOTW (Guru Of The Week -> www.gotw.ca/gotw/)

Merci.

Cela devrait te permettre de switcher rapidement entre le vecteur standard et celui de Qt (tant que tu n'utilises pas les spécificités d'itération de Qt)[1], mais peut-être pas pour les chaînes si justement tu recherches une dont l'interface est mieux foutue.

[1] quoique je j'ai un doute, car j'ai l'impression (je peux me tromper) que le COW pousse au passage par copie, plutôt que par référence constante.

Je suis sans doute mal expliqué.Dans la V1 de l'application, il n'y aucun typedef,que des conteneur/string ébasé sur wxWidgets et écrit en dûr dans mon code.

[JolyLoic]

Disons que certaines classe de la STL gene std::string sont un peu (beaucoup) des classe foure-tout assez mal foutu (AMHA).
Et puis quand tu compare avec celle de Qt (http://qt.developpez.com/doc/4.3/qstring-members/) ya pas photo

Euh, tu veux montrer un fourre-tout encore plus gros, c'est ça

De mémoire, les seules fonctionnalités de QString que n'avait pas std::[w]string + boost sont :
- Des conversions dans tel ou tel encodage pour l'I18N (mais il y a moyen de se faire ce genre de choses avec d'autres libs)
- Une gestion multibyte (les QString sont en UTF16).
- Le COW (est-ce bien ou pas...)
- Une spécification claire de ce qui se passe en multithread.

Cela devrait te permettre de switcher rapidement entre le vecteur standard et celui de Qt (tant que tu n'utilises pas les spécificités d'itération de Qt)[1], mais peut-être pas pour les chaînes si justement tu recherches une dont l'interface est mieux foutue.

Quel est l'intérêt d'utiliser les conteneurs de Qt, si c'est pour utiliser l'interface à la mode STL uniquement ? (ps : J'ai déjà du mal à voir leur intérêt en utilisant l'interface spécifique...)

[1] quoique je j'ai un doute, car j'ai l'impression (je peux me tromper) que le COW pousse au passage par copie, plutôt que par référence constante.

Quand je développais avec Qt, je faisais quand même un minimum attention au passage par référence constante, mais je suis peut-être une exception. Et puis il faut avouer que tous mes aspect métier restaient en C++ pur, et donc que ce genre de choses arrivait assez rarement.

[Alp]

Hors sujet : Loïc je ne t'ai jamais vu aussi objectif, dis-moi

Davidbrcz > pour une telle application, cela n'est peut-être pas la peine de te prendre autant la tête.

Tu ne vas quand même pas minimiser les appels à Qt pour une appli qui change ton fond d'écran.

Par contre, pour des applis de production, il serait intéressant de comparer ces 2 types de code :
- C++ + Boost ( + ASL ( + Loki ?) etc.)
- C++ + Qt ( + autres bibliothèques liées à Qt )

Généralement, développant des applications graphiques juste pour un usage personnel (ou pour un proche/ami, quoi), je préfère m'immerger dans le framework Qt et tenter de l'utiliser au mieux.

Ceux qui ont déjà utilisé Qt dans leur boîte, vous avez des commentaires ?