Quelqu'un aurait-il fait des benchmarks pour tester les containers de Qt avec la STL ? ce serait interessant de savoir pour choisir ou du moins aider ...
merci
Version imprimable
Quelqu'un aurait-il fait des benchmarks pour tester les containers de Qt avec la STL ? ce serait interessant de savoir pour choisir ou du moins aider ...
merci
Linux Mag avait fait un test, la STL état plus rapide.
plus rapide de combien ?Citation:
Envoyé par Miles
c'etait significatif comme difference ?
Je ne me souviens plus du tout, ça date d'il y a 2 ans environ.
Quel rapport avec Tulip ? ;)
Faut-il utiliser les containers de Qt ?
Quels sont vraiment les avantages en pratique ?
Pas de copie, surtout.
on m'a tellement dit sur ce forum que le cow etait une mauvaise chose que maintenant je me mefie 8OCitation:
Envoyé par Miles
... donc tout le monde est d'accord pour n'utiliser que les containers de Qt ?
Pas de copie pour Qt, en général pour les autres conteneurs, il y a copie lorsqu'il y a copie d'un conteneur.Citation:
Envoyé par epsilon68
Tu les utilises tout le temps maintenant ?
tu les previlégies a la STL ?
Jamais, je ne fais presque plus que du Python ou du C++ presque pur.
y a-t-il un gros avantage a se separer de Qt ?
À supposer que je vienne à utiliser QT, je me vois mal privilégier leur conteneurs.
Tout dépendra du sous-système considéré.
- Coeurs (métier) des systèmes -> SL.
- IHM -> QT.
Ils ont fait leurs propres conteneurs pour les plateformes qui n'ont pas de STL. Si on ne vise pas ce genre de plateforme, ça ne sert pas à gardn chose de les utiliser, à mon avis.
Pas mieux.Citation:
Envoyé par Luc Hermitte
La regle generale, c'est de ne pas introduire des dependances sur ce qui n'en a pas reellement besoin. En particulieur le coeur ne doit pas dependre de l'UI.
Si les conteneurs de la SL ne conviennent pas -- en general en ce qui concerne les perfs, si on n'atteinds pas le niveau de perf cible etabli avant de faire des mesures -- les remplacer par des conteneurs ayant la meme interface mais plus adapte (exemple, avoir un vector optimise pour le cas ou il n'y a qu'un element dedans).
Je suis principalement d'accord mais je dois dire que leur doc est particulierement bonne et que je ne connais pas chaque compilo comment ils ont implementé la STL alors je m'étais dis que Qt nous protegeait de cela justement.Citation:
Envoyé par Jean-Marc.Bourguet
Je sais que KDE n'utilise que les conteneurs Qt, ils ont vraiment eu trop de problemes avec la STL et passé trop de temps a patcher leur code.
Je dois dire que j'avais eu aussi pas mal de surprise avec VC6 mais bon maintenant je pense que c'est réglé mais ... ?
Le projet KDE a par essence une dependance forte sur QT et une influence forte sur QT. Ses choix sont peu pertinents pour ceux qui n'ont pas la meme dependance et ni la meme influence.Citation:
Envoyé par epsilon68
Nous utilisons pour le moment QT pour l'interface graphique. Pourtant dans le code que j'ai ecrit rien ne depend directement de QT. Il faut dire que nous utilisions Motif precedemment. Et rien dans le code hors GUI ne dependait de Motif. Resultat la transition a ete relativement douce.
D'un point de vue gestion de projet, introduire des dependances est a des desavantages, car ca gene l'evolution, ca gene la recuperation dans d'autres contextes. Maintenant, introduire des dependances peut avoir des avantages... il faut simplement les mettre en balance avec la probabilite qu'elles introduiront des couts dans le futur et l'ampleur de ces couts.
je suis de ton avis mais Qt permet aussi de coder plus vite. C'est une question dure a repondre, je suis tout le temps assez balancé. Aussi on peut se poser la meme question avec Boost ...Citation:
Envoyé par Jean-Marc.Bourguet
en fait je crois que je ne considere pas Qt comme un GUI framework, mais plutot comme un framework entier avec une grosse partie UI.
Je pense que je vais utiliser boost et Qt core dans mon code metier
et Qt dans le code UI.
Ce que j'ai lu sur la STL a travers les compilateurs et les plateformes me disent de me mefier de la STL, mais bon a la fin si j'utilise ceux de Qt, j'utiliserais de toute facon les algo de la STL. L'avantage de Qt c'est sa doc ... incroyablement bien faite. Mes plateformes sont Windows / Mac / linux alors je ne pense pas rencontrer de plateforme particuliere.... alors je vais quand meme essayer d'utiliser la STL autant que possible.
autre question: comment vous faites pour retourner une collection ?
par exemple:
vector<string> tokenize( const string &s, char sep )
a l'utilisation:
vector<string> tokens = tokenize(string("bla;la;li;lere"), ';')
c'est minimum 2 copies je pense (votre confirmation?)
alors preferez-vous de la passer en parametre ?
void tokenize( vector<string> &tokens, const string &s, char sep )
la je pense c'est optimal mais c'est moins jolie et moins pratique je trouve.
Comment vous faites ?
Les collections de Qt sont-elles plus efficaces dans ce cas ? (en minimisant les copies avec le COW)
Plus optimisé mais pas forcément plus joli à écrire :Citation:
vector<string> tokens = tokenize(string("bla;la;li;lere"), ';')
c'est minimum 2 copies je pense (votre confirmation?)
Code:
2
Complétement. Perso je ne trouve pas ça moins joli ou moins pratique.Citation:
alors preferez-vous de la passer en parametre ?
void tokenize( vector<string> &tokens, const string &s, char sep )
a je pense c'est optimal mais c'est moins jolie et moins pratique je trouve
Avec les collections de QT tu auras un prix moindre sur les "mauvais" compilos qui sont moins forts pour effectuer des RVO et RNVO -- vu qu'avec les "bons" il n'y aura pas de copie. Tout le prolème est de savoir "est-ce que le compilo saura appliquer le R(N)VO dans cette fonction ?"
Par contre tu auras un prix permanent pour les accès -- en gros un surcout par itération, ou un surcout par appel à [] si je ne me trompe pas.
Cf l'article de linux mag pour un benchmark contre la STL de GCC
D'ici un paquet d'années, tu ne te poseras plus cette question -> arrivée des rvalue references en C++0x qui permettront d'avoir une sémantique de déplacement sur les conteneurs standard. Le COW comme technique d'optimisation des retours par valeur va fortement perdre de son intérêt.
PS: tes articles qui critiquent la STL, ils ont quel age ? Ils parlent de quelle implémentation et de quel compilo ?
Il n'y aucune copie dans ce code avec un compilateur correct.Citation:
a l'utilisation:
vector<string> tokens = tokenize(string("bla;la;li;lere"), ';')
c'est minimum 2 copies je pense (votre confirmation?)
Enfin si, y'a la copie de la chaîne littérale dans string, mais je pense pas que tu parlais de ça.
C'est différent.Citation:
alors preferez-vous de la passer en parametre ?
void tokenize( vector<string> &tokens, const string &s, char sep )
la je pense c'est optimal mais c'est moins jolie et moins pratique je trouve.
Le code précédent permet simplement de créer un nouveau vecteur (ce qui signifie que tu auras besoin de copier -- mais pas en C++0x où on pourra se contenter de déplacer -- si ce n'est pas une initialisation), celui-ci permet d'en modifier un existant.
Ce n'est pas plus optimisé dans ce cas avec un compilateur qui fait de la NRVO. (c'est même légèrement moins bien en fait, tu fais d'abord un appel au constructeur par défaut)Citation:
Plus optimisé mais pas forcément plus joli à écrire :
Code:vector<string> tokens; tokenize(string("bla;la;li;lere"), ';').swap(tokens);
Par contre c'est pas mal si tokens est déjà initialisé à quelque chose. Un compilateur C++0x fera cependant la même chose voire mieux de manière plus jolie avec un code naturel.
Je n'ai pas pu trouver l'article dont tu parlais ...Citation:
Envoyé par Luc Hermitte
moi j'ai lu beaucoup de discussion sur le forum KDE.
J'aurais vraiment bien aimé avoir des chiffres et/ou du retour d'experience ...
a+
J'ai verifié si gcc 4.1 sur mac copiait la collection de retour.
ca marche ! pas de copyCode:vector<TestCopy> test = getTokens();
et la il y a copy :-/Code:
2
donc il faut utiliser swap ?
mais comme le code suivant ne compile pas parce que ce n'est pas possible d'avoir une reference sur un objet temporaire, peut-on vraiment avoir confiance dans le code ci-dessus ?Code:
2
de maniere générale, connaissez-vous des eventuels problemes (effets de bord) a swap ?Code:
2
Linuxmag # 79, pp72+, feuilletable ici : http://www.ed-diamond.com/feuille_lm79/index.html
Pour le swap, seul le premier devrait fonctionner non ?
Sinon, comme je l'ai dit, si tu as un compilateur qui fait les rvalue references et une bibliothèque standard qui l'exploite, ça fait le swap automatiquement.
ca marche quand dans le casCitation:
Envoyé par loufoque
mais pasCode:vector<TestCopy> test = getTokens();
dans le dernier cas il faut faire manuellement le swapCode:
2
C'est la meilleure methode donc ?
C'est marrant, j'ai tout expliqué en détail plusieurs fois, mais tu ne comprends pas.
Bien sûr que ton deuxième code copie -- nul besoin de tester -- ce n'est pas une initialisation.
Et ce deuxième code ne copie pas (ou plutôt, ne copie pas les données, le pointeur lui-même etc. sont quand même copiés) si tu as une bibliothèque standard qui exploite les rvalue references.
Si tu veux, essaie avec ConceptGCC 4.3 alpha 6. Tu as des binaires pré-compilés sur leur site. Il te faudra néanmoins écrire ta propre implémentation de vector, car la version fournie est celle de libstdc++ qui n'exploite pas les rvalue references.
Par contre, le code que tu as donné précédemment
ne devrait pas fonctionner.Code:
2
Alors que
, si.Code:
2
Oui. Note que ce n'est pas une reference sur un objet temporaire qu'il est impossible d'avoir, c'est une reference sur une lvalue (objet temporaire caracterise l'objet, lvalue caracterise la vue que tu as de l'objet; dans certains cas -- un membre qui retourne une reference avec *this par exemple -- tu peux modifier la vue que tu as de lvalue en reference).Citation:
Envoyé par epsilon68
Non.Citation:
de maniere générale, connaissez-vous des eventuels problemes (effets de bord) a swap ?
Tu vis dans quel monde? Je n'imagine pas pouvoir en utiliser avant 2011-2012 dans du code en production.Citation:
Envoyé par loufoque
À mon avis ça arrivera sûrement dans GCC 4.4, si ce n'est avant.
Petit rappel, gcc 4.2 est sorti il y a moins d'un mois. Ce n'est pas dans la liste des projets pour gcc 4.3. gcc 4.4, c'est dans environ deux ans vu les cycles de gcc.Citation:
Envoyé par loufoque
Ca nous met deja en 2009 pour ce qui sera vraissemblablement le premier compilateur release avec cette possibilite. Compter deux ou trois ans pour les autres compilateurs et stabiliser les choses avant de rentrer en production ne me semble pas excessif, surtout quand on tient compte de nos cycles a nous (des nouveaux compilateurs, ca ne s'introduit pas n'importe comment).
En fait, ce lien dit que les rvalue references sont déjà dans le mainline et seront intégrées dans GCC 4.3.
Ah bon? C'est dans la description de la branche oui. Mais je ne vois pas les rvalue references dans ce qui est deja integre pour gcc 4.3 (qui n'est pas sur cette page mais sur une autre qui s'appelle d'ailleurs "Status for Experimental C++0x Support in GCC 4.3") et ce n'est pas dans la liste du wiki pour gcc 4.3 (mais la liste n'est apparemment pas a jour puisqu'elle a une mention pour les variadic templates qui contredit celle-ci).Citation:
Envoyé par loufoque
Et ca ne change pas grand chose sur le fond. On est a un an ou deux d'avoir un premier support experimental dans certains compilateurs. Il faudra du temps en plus pour avoir un support solide sur tous les compilateurs. Ce qui est la condition necessaire pour utiliser quelque chose en production.
Il y a marqué que cette fonctionnalité est déjà dans la mainline, c'est à dire la branche principale.
C'est marqué expérimental parce que le standard n'est pas encore ratifié. Donc tout peut changer.
La fonctionnalité ne serait néanmoins pas intégrée si elle n'était pas stable.
Pour un certain nombre, voire même la plupart, de projets on peut se permettre de choisir un compilateur cible avec lequel on travaille.
Non, c'est marque que dans la branche C++0x comme dans mainline, il y a des choses concernant C++0x. La liste de ce qui est disponible dans la branche suit. Pour mainline il faut suivre le lien en dessous et les rvalues references n'y sont pas. (En repassant sur la page, je vois une incoherence/imprecision; il n'y a pas de liens vers un patch pour les rvalue references alors que la description a l'air de dire que seuls les points avec un lien patch ne sont pas dans mainline)Citation:
Envoyé par loufoque
Je crois que nous avons des criteres differents en ce qui concerne la stabilite necessaire avant de commencer a utiliser professionnellement quelque chose.Citation:
C'est marqué expérimental parce que le standard n'est pas encore ratifié. Donc tout peut changer. La fonctionnalité ne serait néanmoins pas intégrée si elle n'était pas stable.
Je n'ai pas une experience telle que je puisse faire des stats sur les projets en general. En tout cas, dans aucun projet sur lequel j'ai travaille professionnellement on utilisait moins de 3 compilateurs differents, sur des architectures differents avec des OS differents (enfin, pour le moment c'est surtout des variantes d'Unix ce qui simplifie pas mal).Citation:
Pour un certain nombre, voire même la plupart, de projets on peut se permettre de choisir un compilateur cible avec lequel on travaille.