Discussion :

[epsilon68]

le probleme c'est ce qui va autour de unicode..
Dans boost il n'y a rien, glib::ustring est gtk/gnome, ICU est vraiment un trop gros. Dans tous ca il y a aussi un probleme de threads et de gerer toutes les librairies... et pour avoir quoi au final ?
si mon but est d'afficher avec Qt je crois qu'il faut etre coherent.

avoir un model metier independant de Qt, c'est tres bien mais au cout de nombreuses dependances et d'etre embeté avec les threads, je crois encore qu'il faut etre coherent.

J'utilise libxml que j'interface avec Qt.

Sinon je comprend que Qt n'utilise pas les exceptions, et cela a deja été argumenté maintes et maintes fois sur les forums.
ainsi que pour moc.

Comprends bien que l'energie deployé ainsi qu'une maintenance accrue en voulant a tout prix se passer de Qt est a mon humble avis completement inutile.

Je vais plutot orienté le design pour faciliter le decouplage en cas de separation avec Qt

a+

[Aurelien.Regat-Barrel]

Hello, je débarque.
Au niveau du développement, la grande différence à mon avis est que boost est développée selon des contraintes techniques, et Qt selon des contraintes business. C'est généralement le cas quand on compare un produit open source à un produit commercial.
Ca veut dire, en gros, que boost est développé afin d'être la plus proche de la philosophie C++, et Qt pour coller au mieu à l'attente de ses clients, et tans pis si c'est pas 100% C++.
Donc faut se méfier des argument "c'est mieux". Souvent ce qui est le mieux, c'est ce qui coute le moins cher. Si tu as besoin de manipuler des threads dans ton programme commercial non GPL, tu peux utiliser gratuitement boost thread, ou payer une licence Qt pour chaque plateforme visée... Si tu as déjà une licence Qt pour développer une IHM, que ton code repose massivement sur Qt à cause de ça, pourquoi se compliquer à utiliser boost quand Qt fait grosso modo pareil, pour les fichiers, les threads ou ce que tu veux.
Ainsi, pour les strings, si 90% de ton code utilise Qt, il est préférable d'utiliser QString partout. Si tu n'utilises Qt que pour faire 2/3 trucs, ça se discutte.
Maintenant, si tu as besoin de manipuler de l'unicode, std::string n'est pas la solution. Certains disent même que le C++ n'est pas la solution. Donc, il te faut une lib spécilisée pour les strings C++. Qt est candidates (GPL/payante). Si tu n'as pas besoin de ses autres services, ou que à part ça boost fait l'affaire, ben vaut peut être mieux chercher autre chose...

C'est plus le contexte général qui va argumenter pour l'une ou l'autre lib. Moi j'utilise essentiellement Qt, et un peu boost (shared_ptr, matrices, ...). Mon code repose aussi essentiellement sur QString, parce que au final mes strings finissent dans des fonctions Qt (affichage etc...), donc faudra convertir mes std::strings. Par contre je n'utilise pas les conteneurs de Qt, et préfère ceux de la STL, car standards, et que j'aime pas ceux de Qt.

Après, pour le reste, ça se discutte. Qt, ils ont des mecs compétents c'est sûr, mais chez boost c'est pas des ânes non plus. Le COW a été à la mode un moment en C++ standard, VC++6 l'utilisait pour ses std::string. Et puis ils ont fait machine arrière, il doit y avoir une raison... (parrait que c'est incompatible avec le standard).

Les signaux... En Qt tu les utilises partout pour l'IHM etc... A mon avis ce serait stupide d'utiliser en même temps ceux de boost. Par contre, si tu en as besoin ponctuellement dans du code qui jusque là se passe de Qt... Les signaux Qt, c'est l'artillerie lourde. C'est inter thread c'est vrai (depuis Qt4), mais à grand coup de marshalling de paramètres (tu dois coder ton marshaller si ce n'est pas un type de Qt), et pour ma part j'ai eu des déceptions. Aparament ça déconne à ce niveau sur QString, j'ai pas eu le temps de bien approfondir et la mise en liste FIFO (asynchrone) m'a causé des problèmes. Maintenant j'évite des passer des paramètres de cette manière.

Mon avis sur Qt4 est mitigé. Y'a des trucs très bien, et d'autres que j'aime pas. Ils ont Java'isé leur API, et avec Qt 4.0 j'ai eu l'impression d'un produit innachevé. Leur système de model/view, sur le papier c'est bien, mais dans la pratique, recoder (car le portage depuis Qt3 s'est révélé être un recodage) une liste view model s'est révélé super prise de tête, et beaucoup plus long que l'équivalent en Qt3.
Les exceptions, c'est galère aussi. Si une exception est levée dans un slot, ça tue tout, et c'est la poisse. Pour le COW, tu peux aller à la recherche de critiques intéressantes sur le forum (celles de Loic Joly noramment).

Mais en gros Qt ça reste quand même une très bonne option. On peut en discutter si tu fais pas d'IHM, mais dès qu'il y en a, à mon avis y'a pas photo. A la question Qt vs boost, moi je répond Qt + boost. Pour les parties qui se recoupent, faut choisir ce qui est le plus simple / moins couteux à mettre en oeuvre.

[epsilon68]

boost est développée selon des contraintes techniques, et Qt selon des contraintes business.

entierement d'accord, c'est exactement ca.
et de maniere generale je suis entierement d'accord avec ton post.

a+

[Luc Hermitte]

J'ai lu sur le net que quelques implementations de la string utilisait aussi le COW avec des mutex ce qui rendait le tout assez lent. J'ai aussi lu un article sur l'implementation d'un parser, qui etait 25% plus lent en utilisant les string que les char*, notamment du à de nombreuses recopies.

Je ne dis pas c'est bien ou c'est pas bien, mais pourquoi Trolltech irait dans cette direction si ce n'etait pas la bonne ? ils ont pourtant des programmeurs talentueux ....

C'est une excellente question que je me pose parfois. Je veux bien qu'ils versent dans le NIH pour des contraintes business de support de compilos démodés et/ou embedded (qui est un C++ qui se rapproche plus du C++ du temps de l'ARM que du C++ 98 -- et encore, les templates existaient) mais quand même.
Cela me fait penser à un truc que j'ai entendu Blanchette (?) dire. En gros : "maintenant (QT4-15j) QString est optimisée, les copies des QString vides ne couteront plus rien." Cela m'avait un peu surpris : quelques temps avant Aurélien avait écrit (dans le FAQ je crois) que les dernières std::basic_string de VC (=> dinkumware) se passaient d'allocation en cas de petites chaînes. Ce n'est qu'il y a peu de temps que j'ai appris (sur artima, ou dans imperfect C++, je ne sais plus) le nom de cette technique bien connue : small string optimization.
Pourquoi une technique rodée et connue efficace est ignorée ? Pourquoi cela sens le syndrôme du NIH comme ça ? S'ils ont de bonnes raisons, j'aurais bien aimé les lire.

Pour aller jusqu'au bout des optims, il aurait fallu distinguer des classes de chaînes immuables qui auraient un comptage de références atomiques (ou pas, si pas de threads), et des chaînes modifiables à la basic_string. Côté utilisation, on paie alors une explosion de types et une complexité accrue pour le newb' qui ne saura plus quoi choisir, il ne sait déjà pas passer ses string par références constantes.
ASL d'Adobe (que j'ai tendance à voir comme l'extension IHM de boost : un labo dans le labo) propose ce genre de chaînes immuables (il me semble qu'ils distinguent même les constantes littérales des immuables contruites à l'exécution)

concernant le COW, as-tu lu des trucs serieux sur le net qui desapprouvait cette methode ? des comparaisons ? et plus specialement sur Qt ?

J'avais lu des propos intéressants sur le sujet dans fr.comp.lang.c++. De James Kanze à tous les coups.
NB: les basic_string de GCC 3.3 utilisaient encore le COW il me semble.

De nombreuses fois j'ai lu preferer boost pour le model metier parce que c'est mieux, plus standard etc. Si pour une fonctionnalité on a le choix entre boost et Qt, alors j'aimerais des arguments rationnels, et non pas "ca utilise le COW alors c'est nul" (j'exagere un peu).

Le problème du COW, à en lire les retours d'expérience d'implémenteurs de la SL, c'est qu'il me fait craindre un syndrôme du NIH. Syndrôme qui pour moi est un point négatif dans toute bibliothèque que j'ai à considérer. D'où que j'aurais bien aimé voir un article par trolltech sur les diverses études qu'ils ont pu mener et les raisons de leur choix final.
Ce n'est pas du tout, pour moi, un problème d'optimisation. Mais un problème de savoir pourquoi diable ils font les originaux et ignorent les expériences des concurrents ? Mon problème est tout autre.
(Ceci est évidemment ma plus que subjective vision de la chose)

[...]unicode

Un peu par hasard, je suis tombé sur une discussion au sujet de l'unicode. Il y a quelques éléments intéressants dans la discussion.
news://comp.lang.c++/q2egv2-lf.ln1@darkstargames.dnsalias.net

hummm .... va faire de l'opengl et un IHM avec boost.

ASL! (Anciennement Adam et Eve)
C'est prometteur. Le noyau est boost. Mais ce n'est pas encore prêt pour de la production, hors Adobe, je pense.

Si tu as besoin de manipuler des threads dans ton programme commercial non GPL, tu peux utiliser gratuitement boost thread, ou payer une licence Qt pour chaque plateforme visée...

Tu as quantité d'autres frameworks. Certains plus matures, expérimentés, et lourds parfois comme ACE.
On a toujours quantité de choix possibles. xerces-c (dont je n'aime vraiment pas la gestion des chaînes) par exemple pour l'XML, ...

C'est bien, je pense qu'Aurélien a globalement mis tout le monde d'accord

[Matthieu Brucher]

C'est quoi NIH ?

[Aurelien.Regat-Barrel]

Not Implemented Here je suppose : syndrome bien naturel mais qui coute une fortune en développement logiciel. "C'est pas développé par nous, donc c'est de la merde, donc on refait".

[Luc Hermitte]

Tu supposes parfaitement bien.

Petite note supplémentaire par rapport à mes propos. Il faut juste reconnaitre que la structure des std::basic_string, ses itérateurs, ses opérations qui invalients itérateurs et pointeurs, ... font que la mise en place d'une stratégie de de COW est particulièrement complexe.

[Matthieu Brucher]

J'aurai dû m'en douter avec la réimplémentation de la STL, ...

[epsilon68]

ICU utilise le COW

et j'aime bien la clarté du code que cela genere avec Qt.
par ex on retourne une collection proprement sans pointeur sans memoire a gerer.

[loufoque]

le probleme c'est ce qui va autour de unicode..

L'Unicode est quelque chose de très complexe, bien plus qu'on ne le croit.
Le support de Qt est très partiel, il y a vraiment très peu de choses en fait.

[epsilon68]

L'Unicode est quelque chose de très complexe, bien plus qu'on ne le croit.
Le support de Qt est très partiel, il y a vraiment très peu de choses en fait.

Avance peut-etre des arguments ?

[epsilon68]

L'Unicode est quelque chose de très complexe, bien plus qu'on ne le croit.
Le support de Qt est très partiel, il y a vraiment très peu de choses en fait.

je ne vois vraiment pas pourquoi il est partiel,
en plus ils font toute la chaine unicode, jusqu'à l'affichage

je ne sais quoi dire !

[loufoque]

Ne supporte que l'UCS-2, ce qui est reflété dans l'interface. Déjà, on ne peut stocker que la moitié d'Unicode.
Fonctions membres additionnelles pour composer, décomposer, normaliser, et comparer en fonction des locales systèmes. Ces fonctions sont bien gentilles mais pour être utiles elles devraient être utilisées automatiquement.
Il n'y a donc pas de support réel pour les opérations au niveau des grapheme clusters.

Donc avec Qt, on a que é (U+00E9) != é (U+0065 + U+0301).
De même, il est possible que si je recherche "foo", il me trouve "foô" mais en laissant le code unit pour l'accent de côté, rendant potentiellement la chaîne invalide en fonction des traitements suivants. Et bien sûr, si je cherche le é combiné avec le é normal, je ne trouve rien.
Il est vrai, cependant, que de nombreux logiciels ne gèrent pas les grapheme clusters et ne sont même pas capables de les afficher correctement. Par exemple, en fonction de la police et des systèmes d'affichage utilisés, les deux é définis précedemment peuvent s'afficher légèrement, voire carrémment différemment.
D'après Unicode, cependant, ce sont des séquences équivalentes.

Et les fonctions toUpper etc. sont aussi très limitées.

[epsilon68]

Qu'est ce que tu proposes d'utiliser alors ?

pas glib::ustring avec de l'utf-8 j'espere apres les arguments avancés ....

[loufoque]

Il n'y a pas vraiment d'outil pratique qui fasse cela.
Néanmoins il est bon de savoir que de nombreux outils qui soit-disant gèrent unicode ne le gèrent qu'en partie.

En tous cas, Glib::ustring c'est déjà mieux.

[epsilon68]

Donc avec Qt, on a que é (U+00E9) != é (U+0065 + U+0301).

en fait je ne pense pas, parce que tu compares des Strings.

dans le code tu ne vas pas faire
ïf( myqstring == "é" )

mais plutot tr("é") pour etre unicode. et la je pense que ca marche.

bref unicode c'est quand meme compliqué.

et puis tu aurais de toute facon le meme probleme avec glib::ustring

[loufoque]

et la je pense que ca marche.

Bien sûr que non.
Il semblerait que tu n'aies pas compris mon explication.

[epsilon68]

Bien sûr que non.
Il semblerait que tu n'aies pas compris mon explication.

le tr() va chercher la string encodé par Qt en UTF-16 donc je pense que ca marche.

peut-etre j'ai tort il faudrait que j'essaie... t'es finalement un eternel incompris ! Pourquoi t'es provisoirement toléré ?