Discussion :

[epsilon68]

Depuis plusieurs jours, je regarde les libs de boost pour les utiliser a la place de Qt lorsqu'elle sont communes.

J'ai posté un message sur les signals et sur unicode pour le filesystem,
ca n'a pas passionné les foules je dois dire.

Ce forum en general m'a progressivement poussé gentiment à regarder du coté de boost et à l'utiliser à la place de Qt quand c'est possible. Alors voici les conclusions que j'ai pu tirer de mes nombreuses lectures et comparaisons. Je vous invite a en faire une critique constructive.

std::string vs QString:
QString est vraiment agreable a utiliser, il manque pas mal de fonction a std::string. Le point le plus important etant l'unicode, auquel wstring ne resoud rien dans le cadre multi plateforme (wchar_t pas portable du tout)

boost::filesystem vs QFile/QDir:
boost est tres agreable a utiliser, mais il manque cruellement l'unicode que je crois necessaire de plus en plus, a commencer par windows.
A ce moment je me suis demandé pourquoi boost n'avait pas de classe boost::string pour gerer ces problemes...

boost::thread vs QThread:
sans hesiter QThread et ses primitives de synchro, plus lisible et plus documenté.

boost::signal vs Qt/Signal:
Qt/Signal marche entre thread. je trouve aussi plus lisible. Au final c'est plus une question d'etre homogene de choisir Qt/signal. Je me suis beaucoup demandé si dans le model metier on ne devait pas utiliser boost plutot, mais au final il vaut mieux etre homogene et faire le soft de facon homogene pour ne pas avoir deux sources de maintenance.

Philosophiquement, il vaudrait mieux se lier a boost, libre et gratuit, c'est aussi pour ca que je me suis serieusement posé toutes ces questions. Au final Qt est vraiment homogene et productif ce qui me fait pencher du coté de Qt, en me disant que KDE a fait les memes choix...

Reste encore boost:bind, boost::function, boost::smart_pointer qui sont tres bien, que je n'hesiterai pas a utiliser si j'en ai un jour besoin. Pour l'instant j'essaie de me limiter dans les dependances.

[roulious]

Note générale pour la suite : je n'ai jamais été confronté aux problèmes d'unicode.

std::string vs QString

Je trouve un désavantage assez gros à QString : l'interface a changé de façon assez radicale entre Qt3 et Qt4 (cf. ascii / toAscii, justified/justify, conversions implicites, ...). Ce qui me gêne beaucoup, pour une classe aussi bas niveau qu'une chaîne de caractères. Du coup, je pencherai plutôt pour std::string, probablement plus stable en raison de son interface plus réduite.

boost::filesystem vs QFile/QDir:

Outre les mêmes changement d'interface que précédemment, j'ai eu des problèmes avec les noms de fichiers dans un environnement Cygwin, Qt ayant du mal avec les séparateurs et boost n'ayant aucun problème.

Je n'ai jamais touché aux threads de boost ni Qt. Concernant les signaux, le modèle utilisé par Qt me gêne dans la mesure où il rajoute des mots clés au langage, ce qui force l'utilisation d'un pré-compilateur.

Philosophiquement, il vaudrait mieux se lier a boost, libre et gratuit, c'est aussi pour ca que je me suis serieusement posé toutes ces questions. Au final Qt est vraiment homogene et productif ce qui me fait pencher du coté de Qt, en me disant que KDE a fait les memes choix...

Du côté de boost, on a aussi la proximité avec le standard (cf. les différents modules de boost inclus dans le TR1). boost a aussi l'avantage d'être plus jeune et donc de supposer des compilateurs de meilleure qualité que ce qu'à dû faire Qt. Dans mon cas, en supposant que j'ai le choix, je laisserai Qt uniquement au niveau GUI, pour pouvoir plus facilement remplacer le GUI par WxWidgets ou autre, en gardant des choses plus standard dans les parties de plus bas niveau. Le découplage interface/traitement me parait une des choses les plus importantes pour produire un code robuste, maintenable et cross-platform.

[Matthieu Brucher]

Boost et Qt n'ont pas du tout le même objectif. A la base, Qt est même orienté embarqué - d'où réimplémentation de la STL -, quand Boost essaie simplement de maximiser ce que le standard propose.

[epsilon68]

Note générale pour la suite : je n'ai jamais été confronté aux problèmes d'unicode.


Je trouve un désavantage assez gros à QString : l'interface a changé de façon assez radicale entre Qt3 et Qt4 (cf. ascii / toAscii, justified/justify, conversions implicites, ...). Ce qui me gêne beaucoup, pour une classe aussi bas niveau qu'une chaîne de caractères. Du coup, je pencherai plutôt pour std::string, probablement plus stable en raison de son interface plus réduite.

plutot se limiter alors ? sinon utiliser les fonctions de boost...
mais ne seront-elles pas sujettes a changer ?

Outre les mêmes changement d'interface que précédemment, j'ai eu des problèmes avec les noms de fichiers dans un environnement Cygwin, Qt ayant du mal avec les séparateurs et boost n'ayant aucun problème.

hum bizarre ... mais bon encore une fois boost::filesystem ne gere pas l'unicode ...

Je n'ai jamais touché aux threads de boost ni Qt. Concernant les signaux, le modèle utilisé par Qt me gêne dans la mesure où il rajoute des mots clés au langage, ce qui force l'utilisation d'un pré-compilateur.

moi je peux comprendre ce pre-processing, il ne me derange pas. Les signaux de Qt sont thread safe, boost::signal non.

Dans mon cas, en supposant que j'ai le choix, je laisserai Qt uniquement au niveau GUI, pour pouvoir plus facilement remplacer le GUI par WxWidgets ou autre, en gardant des choses plus standard dans les parties de plus bas niveau. Le découplage interface/traitement me parait une des choses les plus importantes pour produire un code robuste, maintenable et cross-platform.

Je suis d'accord mais en meme temps le temps passé a utiliser deux libs et a affronter les changements de chaque vaut-il vraiment la peine ?
sur la mailing list de qt, il y a des personnes disant qu'ils ont eu des problemes avec des noms de fichiers et des fichiers unicode, ils ont du changer leur code metier et donc les std::string et les std::iostream. D'autres ont dit qu'a terme leur groupe a prefere etre homogene et convertissent peu a peu leur code avec Qt.
Sur le net, j'ai lu contre-opinion sur std::string et la stl, disant que ce n'etait pas implementé pareil sur les plateformes, d'ou beaucoup de problemes pour la portabilité. Personnellement je n'ai pas eu de probleme sur la stl, mais je veux bien croire que ca doit arriver sur quelques plateformes...
Peut-etre quelqu'un a-t-il deja eu ce cas ?

Sinon Boost me parait etre proche du standard, c'est vrai mais en meme temps aussi etre un laboratoire d'essai, par exemple rien que dans boost::thread ils disent que le systeme des locks peuvent changer d'une release a l'autre.

En outre Boost n'a pas les memes contraintes que Qt et justement peuvent se permettre de changer du tout au tout, contradisant le premier argument sur les strings.

En fait le principal point qui m'inquiete pour le futur c'est unicode, si l'unicode n'est pas gere dans le model metier, alors ouille ouille ouille.

Pour finir, separer le code metier de l'IHM est primordial, mais ne veut pas dire se separer du toolkit. Si tu n'utilises pas les QString mais les std::string dans ton code metier juste pour separer, tu vas te payer les problemes d'unicode dans les dents. Les fichiers xml sont principalement en UTF-8, tu pourra encore te servir des std::string mais adieux le traitement de chaines apres, un char n'est plus == a un caractere.

a+

[Matthieu Brucher]

Les QString utilisent le Copy-On-Write, ce qui n'est plus aussi judicieux, les implémenteurs de bibliothèques ont pas mal changé d'avis à ce sujet, et Qt s'y met après que tout le monde ou presque soit contre. De plus, l'interface a changé de la version 3 à la version 4, et je ne parle même pas des différences de comportement entre la 4.0 et la 4.1 !
Boost.Threads évolue, effectivement, parce que c'est la bibliothèque multithreads, et tout le monde sait que c'est très difficile de concevoir qqch de bien dans ce domaine. Les autres parties ne modifient pas l'interface, elle est stable en général, tout comme pour Qt, donc ce n'est pas un argument recevable

[epsilon68]

Les QString utilisent le Copy-On-Write, ce qui n'est plus aussi judicieux, les implémenteurs de bibliothèques ont pas mal changé d'avis à ce sujet, et Qt s'y met après que tout le monde ou presque soit contre. De plus, l'interface a changé de la version 3 à la version 4, et je ne parle même pas des différences de comportement entre la 4.0 et la 4.1 !
Boost.Threads évolue, effectivement, parce que c'est la bibliothèque multithreads, et tout le monde sait que c'est très difficile de concevoir qqch de bien dans ce domaine. Les autres parties ne modifient pas l'interface, elle est stable en général, tout comme pour Qt, donc ce n'est pas un argument recevable

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 ....

pour le changement d'interface, c'est sur que Qt en a eu pour son compte avec la version 4, mais bon de nombreuses innovations quand meme.
Je connais finalement mal le passé de boost, si tu dis que les interfaces ne changent que tres peu, je te crois, ca me rassure en fait...

Tu utilises aussi Unicode ? pourquoi ils n'ont pas fait une classe qui gerait cela dans boost ? pourtant gnome aussi a refait une classe (UTF-8), libxml ne travaille qu'en UTF-8.

c'est aussi a cause d'unicode que je ne vais pas utiliser boost::filesystem, j'aimerais pourtant, j'aime bien la conception, mieux que Qt je trouve.

Qu'en pensez-vous ?

a+

[Matthieu Brucher]

Les bibliothèques de Boost sont plus élémentaires que la grosse bibliothèque de Qt
En ce qui concerne l'unicode, je ne sais pas

[epsilon68]

Les bibliothèques de Boost sont plus élémentaires que la grosse bibliothèque de Qt
En ce qui concerne l'unicode, je ne sais pas

ne serait-ce que pour l'xml ? non ?

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

Il y a beaucoup de questions que je pose sans reponse

a+

[Matthieu Brucher]

Oui, mais Boost n'as pas de parseur XML par exemple, donc je ne sais pas
Pour le COW, il y a des trucs sur http://www.gotw.ca/ avec des comparaisons, mais pas avec Qt, mais comme Qt n'a rien inventé de nouveau...

[epsilon68]

Oui, mais Boost n'as pas de parseur XML par exemple, donc je ne sais pas
Pour le COW, il y a des trucs sur http://www.gotw.ca/ avec des comparaisons, mais pas avec Qt, mais comme Qt n'a rien inventé de nouveau...

... pas de parseur xml ... comment je vais faire mon code metier moi ?

j'ai lu l'article sur le COW, bon je dois dire que ca ne m'a pas vraiment convaincu. Mais le mieux est peut-etre encore de poser la question a trolltech ? L'article denonce completement le COW comme une fausse optimisation ...

Sinon le COW ne doit pas etre une limite a l'utilisation des QString quand meme, et si ca se trouve votre implementation des std::string utilise le COW ....

au final cette histoire de COW n'est pas un argument je trouve !

[Matthieu Brucher]

Non, ce n'est pas un argument, c'est sûr
De moins en moins de bibliothèques passent par du COW. Qt l'utilise beaucoup parce qu'ils utilisent énormément de sémantique de valeur, ça doit jouer, pour obtenir des copies à faible coût.

[epsilon68]

Non, ce n'est pas un argument, c'est sûr
De moins en moins de bibliothèques passent par du COW. Qt l'utilise beaucoup parce qu'ils utilisent énormément de sémantique de valeur, ça doit jouer, pour obtenir des copies à faible coût.

est-ce que toi tu as remarqué des lenteurs avec Qt et cette utilisation du COW ? moi par experience avec la version 3 de Qt, j'ai remarqué tres nettement une lenteur lorsque je mettais l'option multithread. Par contre avec Qt 4, je n'ai pas remarqué de lenteur. d'ailleurs il n'a plus d'option c'est toujours multithread.

de plus dans les benchmarks sur 1 millions de test c'est une lenteur de l'ordre d'une seconde, alors bon peut-etre que tout est relatif, ceci peut peut-etre avoir une incidence si la base du programme est la manipulation de milliard de caractere avec des traitements sur chacune d'elle, quelque chose comme ca

J'ai comme l'impression que le debat est ailleurs mais je suis content de parler du COW.

J'ai l'impression que l'unicode est incontournable dans le futur proche et utiliser les std::string sur un logiciel qui commence n'est peut-etre pas la meilleure chose. Peut-etre aussi que d'encapsuler QString pour faciliter le changement plus tard est peut-etre une bonne strategie... Encapsuler par des functions templates ?!

non ?

[Matthieu Brucher]

Aucune idée... Je n'ai jamais été encore confronté au problème Unicode, par ailleurs

[epsilon68]

Aucune idée... Je n'ai jamais été encore confronté au problème Unicode, par ailleurs

alors si je resume les avantages de boost:
- gratuit
- plus pres du standard
- c'est mieux
- ca n'utilise pas COW

bon bah ok personne n'a d'experience ou d'avis sur Qt et/ou boost
Quelles sont les modules que vous utilisez le plus ?
et quels avantages / inconvenients vous avez trouvé ?

merci a+

[Matthieu Brucher]

Comme dit, Boost et Qt n'ont pas les mêmes objectifs. J'utilise les 2 dans mes tests aux boulot.
Boost, j'utilise surtout les pointeurs, le MPL, ... quand pour Qt, j'utilise l'IHM, l'XML.

[epsilon68]

Comme dit, Boost et Qt n'ont pas les mêmes objectifs. J'utilise les 2 dans mes tests aux boulot.
Boost, j'utilise surtout les pointeurs, le MPL, ... quand pour Qt, j'utilise l'IHM, l'XML.

comment tu geres les strings alors ? std::string ou QString ou ... ?
ton xml n'est pas en UTF-8 ? il est dans quel caractere code ?
tu utlises boost::signal ? dans quel ca par exemple ?

Quels sont les avantages / inconvenients que tu as pu voir ?

As-tu remarque une certaine lenteur dans Qt a cause du COW ?

a+

[Matthieu Brucher]

Pour l'XML, je ne sais pas trop, je prend l'encodage par défaut
signal, je ne l'ai pas encore utilisé, mais ça ne devrait pas tardé que je me plonge dedans
En ce qui concerne les strings, je suis en QString à l'intérieur de l'IHM, et en std::string à l'extérieur, dans mon code, de sorte à rester indépendant.

[epsilon68]

Pour l'XML, je ne sais pas trop, je prend l'encodage par défaut
signal, je ne l'ai pas encore utilisé, mais ça ne devrait pas tardé que je me plonge dedans
En ce qui concerne les strings, je suis en QString à l'intérieur de l'IHM, et en std::string à l'extérieur, dans mon code, de sorte à rester indépendant.

l'encodage est defini dans le fichier xml par:
<?xml version="1.0" encoding="UTF-8"?>

si tu manipules des fichiers UTF-8 c'est alors vraiment tres bizarre que tu n'ai jamais eu de probleme.... le passage aux std::string est alors mortel !!!

J'ai aussi un autre inconvenient a boost:signal, c'est pour deconnecter un signal, qui ne marche pas avec bind de la maniere suivante

monsignal.connect( bind(..., _1 ) );
et mysignal.disconnect( bind(..., _1 ) );

ne marche pas, il faut recuperer l'objet connection puis appeler disconnect dessus, encore une manip a faire en plus, je trouve ca pas super.

Tu ne ferais pas de gros calculs par hasard ?
t'as pensé au multithread ? openmp ?
pense que les signaux de boost ne sont pas threadsafe.

a+

[Matthieu Brucher]

Je ne mets pas d'en-tête dans mes XML

Je fais des gros calculs, mais je n'ai pas eu le temps d'implémenter le parallélisme dans mes algos - je regarde plus du côté de MPI qu'openMP, car dispo sous Linux directement, et je n'ai pas de mémoire partagée, donc message -

[epsilon68]

Je ne mets pas d'en-tête dans mes XML

Je fais des gros calculs, mais je n'ai pas eu le temps d'implémenter le parallélisme dans mes algos - je regarde plus du côté de MPI qu'openMP, car dispo sous Linux directement, et je n'ai pas de mémoire partagée, donc message -

pas de memoire partagée ? tu travailles pas sur un PC ?