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