Discussion :

[snake264]

Voir mon premier post, la STL n'a pas de fonction me permettant de faire ce que je souhaite, il faut que je la créé moi même et j'avais un peu la flemme donc autant utiliser ce qui existe déjà

[epsilon68]

STL = string pour toi?

ok dans ce cas, mais en fait je suis aussi en train de changer de QString en std::string. Je n'ai pas de traitement vraiment sur les chaines...

[snake264]

Heuu non pas vraiment, STL = Standard Template Library, qui est la bibliothèque standard C++ normalisé par l'ISO.

D'ailleurs un petit conseil si Qt est trop gros pour toi utilise la bibliothèque Boost qui offre plus de possibilités que la STL et est plus performante.

Car malheureusement la STL est pratique mais extrêmement limité

[epsilon68]

je ne comprends pas du tout
en quoi la STL est limité par rapport à Qt?

[snake264]

Qt permet de faire énormément plus de choses que la STL et pour type équivalent (par exemple QVector et std::vector puis QString et std::string etc.) ceux de Qt sont beaucoup plus performant. Idem pour Boost

[epsilon68]

prenons QVector par exemple,
que permet-il de plus que std::vector?

[snake264]

Pour cela à toi de lire la doc, je ne vais pas tout résumer ici

http://qt.developpez.com/doc/latest/qvector/

Mais mis à part certaines méthodes en plus le type est surtout comme je l'ai déjà dit plus performant (donc plus rapide pour la gestion des vecteurs qu'un simple std::vector). Pour voir cela je te laisse aussi le soin de faire des tests de comparaisons de performances.

Mais encore une fois utiliser Qt est un choix conséquent, pour un choix aussi performant mais moins lourd il y a la bibliothèque Boost.

[Goten]

Boost ne propose pas de vector (ou équivalent avec un autre nom) tout simplement parce que eux savent ce qu'est le NIH...

Bref dans du code métier il ne devrait jamais y'avoir de classe en Q quelque chose (des classes qui viennent de Qt quoi). Réserve ça à l'interface un point c'est tout.

[snake264]

Si il en propose :

http://live.boost.org/doc/libs/1_46_...doc/vector.htm

On est pas obligé d'utiliser Qt pour faire que du graphique il existe aussi beaucoup d'applications qui utilisent Qt et qui sont juste des application console

Après c'est chacun fait comme il le sent. Perso pour moi ni boost ni la STL n'offraient ce que je voulais sans faire moi même les méthodes je me suis donc rabattu sur Qt et mon appli n'est aucunement graphique

[Goten]

Non, le lien que tu me donnes c'est un vector au sens mathématique du terme et non au sens de la collection d'objets comme celui de la STL. (qui est mal nommé à mon avis).

[epsilon68]

as-tu fait des benchmarks pour dire que QVector est plus performant que std::vector?

et pourrais-tu me donner un exemple que sait faire QVector et pas std::vector?
juste un seul ca me suffira.

comme a dit Goten, boost ne propose pas de vector ou list pour remplacer std::vector ou std::list.

[snake264]

Elle est pourtant définie comme un container :

http://live.boost.org/doc/libs/1_46_...ept.htm#vector

Mais c'est vrai que c'est pour un usage mathématique pour l'algèbre linéaire, je suis bien d'accord avec toi et me suis mal exprimé, je m'en excuse donc.

Mais d'après la doc je ne vois pas ce qui peut empêcher de s'en servir comme vecteur au sens collection. En créant des méthodes soit même. Mais il est vrai que ça fait du boulot

Enfin perso je ne l'ai jamais utilisé avec boost j'utilise "Boost.Array" qui me permettent de remplacer largement std::vector, std::list, std::queue, etc. Avec des classes perso que je me suis faites moi même.

[snake264]

Désolé epsilon je n'avais pas vu ton message

Pour le benchmark et les quelques différences je te renvoi à cet article :

http://doc.qt.nokia.com/qq/qq19-containers.html

[epsilon68]

mais le lien explique comment les containers de Qt marche, la mécanique interne.

il n'y a pas de benchmark, ni meme d'explication sur ce que pourrait faire QVector en plus de std::vector.

mais alors que t'apporte QVector sur std::vector dans ton cas?
je demande juste un seul exemple, pas plus.

[snake264]

La doc que je t'ai donnée donne quelques différences entre les deux.

Sinon la plus grosse différence se fait par le nombre de méthodes proposées typiquement :

append, constData, contains, data, endswith, replace, etc.

Qui sont autant de méthodes très pratique et que l'on utilise quasiment à chaque fois et qu'avec Qt on n'a pas à recoder.

C'était un exemple parmi d'autres. Si tu veux vraiment avoir des exemples lis les 2 docs que je t'ai donné tu aura déjà une bonne idée sur les différences Je te conseil aussi de lire la doc de std::vector en complémentaire.

[gl]

C'était un exemple parmi d'autres. Si tu veux vraiment avoir des exemples lis les 2 docs que je t'ai donné tu aura déjà une bonne idée sur les différences Je te conseil aussi de lire la doc de std::vector en complémentaire.

Pour savoir ce que la STL permet de faire avec les std::vector (ou avec tout autre de ces containers d'ailleurs), il faut non seulement lire la doc correspondant à std::vector mais aussi (et surtout) celle sur les algorithmes. En effet, la STL est conçue de manière à proposer peu de traitement en tant que méthode membre des container mais par contre plusieurs algorithmes qui travaille sur des paires d'itérateurs (les algorithmes étant décorrélés des containers).
Bref la STL ce n'est pas juste des containers mais bien le trio container + itérateurs + algorithmes.

[JolyLoic]

Un petit extrait de cette doc :

Whereas STL's containers are optimized for raw speed, Qt's container classes have been carefully designed to provide convenience, minimal memory usage, and minimal code expansion. For example, Qt's containers are implicitly shared, meaning that they can be passed around as values without forcing a deep copy to occur. Also, sizeof(QXxx) == sizeof(void *) for any Qt container, and no memory allocation takes place for empty containers.

Qt's containers fully take advantage of partial template instantiation to provide different implementations depending on the data type that is stored. Qt solves the code expansion issue that arises in conjunction with C++ templates by putting most of the container code in non-template internal classes such as QListData and QMapData, making Qt's containers particularly well suited for embedded programming.

Donc, déjà, c'est moins performant, ils le disent eux-même.

Ensuite, le COW, ça cause plein de problèmes quand on essaye de travailler en multithread. Les std::string du C++ étaient prévue pour qu'une implémentation COW soit possible, et à un moment, la plupart des gens utilisaient une telle implémentation. Mais les benchs ont montré que c'était plus une pessimisation qu'autre chose, de moins en moins de gens les ont utilisés, et désormais en C++0x, il n'est plus possible d'avoir du COW pour les strings. De plus le principal use case pour le COW qu'ils citent (passer par valeur à coût réduit) me semble peu justifié (il suffit de passer par référence constante, et on a pareil, mais sans COW, sans lock, sans rien).

Le fait de ne pas avoir d'allocation pour un conteneur vide est aussi probablement vrai dans toutes les implémentations de la STL (du moins pour vector).

Pour le coup du code bloat, Bjarne a depuis toujours sur son site un bout de code qui montre comment l'éviter pour les std::vector en utilisant une spécialisation sur T*. Rien de nouveau donc sous le soleil. Je ne sais pas dans quelle mesure toutes les implémentations utilisent ou pas cette technique.

Je ne dénigre pas Qt, je pense qu'en C++, on n'a probablement pas mieux pour faire de l'IHM actuellement. Mais leur choix de refaire ce qui existe ailleurs, peut-être justifiable dans la version 1 de la biblitohèque, quand la STL n'était pas assez stable sur toutes les plateformes, ne me semble pas très pertinent en nos jours.

(ps : Je ne pense pas qu'Epsilon ait vraiment besoin de lire la doc de std::vector)

[dragonjoker59]

Pour en revenir au problème initial, en fait la solution que j'ai proposée fonctionne (je m'en sers sous Windows, avec VS2008 et MingWin, et sous Linux avec GCC) mais en ne mettant aucun argument au constructeur de std::locale, du coup il utilise la locale globale:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
    std::locale l_loc;
    std::use_facet <std::ctype <wchar_t> >( l_loc).widen(  & my_string[0], & my_string[size()], & my_wstring[0]);

Sinon, pour l'erreur de compilation que tu rencontrais, à part #include <locale>, je ne vois pas pourquoi ça ne compile pas

[screetch]

chez moi ton code utilise la locale C qui est ascii 7 au lieu de cp1252 (europe du nord) je crois

[dragonjoker59]

Et la conversion est correcte ou pas ? (à tester avec un texte à accents)