Discussion :

[3DArchi]

concernant les mise à jour, ça ne sert à rien de suivre le projet comme un petit chien

C'est pas faux. C'est comme ça qu'on se retrouve avec encore des projets en Visual 6

[firebird_dev]

Je trouve que boost est plus un phénomène de mode qu'autre chose.
Certes il apporte beaucoup à l'évolution du C++, et notamment en rajoutant le plus important dans tr1 et C++0x (C++1x n'existant plus comme nom pour la remarque).

Il exploite complètement la métaprogrammation. Et j'ai un avis très mitigé à propos de la métaprogrammation. Parfois cela est génial, parfois c'est une horreur. Et dans ce cas là une librairie comme Qt me parait 100x plus clair et légère d'utilisation.

De plus tout ce qui est vraiment indispensable est déjà dans tr1. Et C++0x va apporter la cerise sur le gâteau. Et encore moi je dis que tout cela arrive trop tard (10 ans de retard).
Aussi c'est une librairie énorme, et sont installation est clairement mal découpée. Je cite un exemple grotesque :

domCollada, dans ses dernières versions a adopté boost::filesystem. Ils ont à tout casser 5 lignes d'utilisation de boost. Le problème c'est qu'ils on fait ce choix stupide et que cela contraint d'installer boost et de le lier à son projet.
Tout ça pour une histoire de '/' '\\' et de working directory. Le plus trollesque est qu'ils fournissent une version de boost avec leur package Windows, mais que cette version ne fonctionne pas avec VC2010, alors il est indispensable d'installer boost et de modifier les projets... => FASHION

Donc sont utilisation est parfois abusive et vraiment pas justifiée.
De plus il existe un conflit par exemple avec le define signals de boost et de Qt (enfin ça c'était il y a 3 ans, maintenant je ne sais pas si c'est toujours un soucis).

Aussi pour ce qui est thread, mutex, je trouve mieux fait ce que propose Qt ou encore ce que j'ai recodé moi même que ce que propose boost à ce sujet.

Je n'ai jamais utilisé boost::graph mais je suspecte que bien d'autre libs libres font aussi bien (voir mieux).

Donc je vois boost comme un laboratoire géant, mais pas comme une solution professionnel.

Autre point, sous Linux il est très facile d'exploiter boost, alors que sous Windows c'est moins pratique à installer. De plus l'installeur copie des .lib de 200Mo un peu partout, et en 2 versions, ce qui fait qu'on se retrouve avec plusieurs Giga d'occupé pour une lib principalement template... WTF ?

Donc à mon avis boost ne sert à rien si ce n'est qu'à apporter ce qui à toujours manquer au C++, avec 10 ans de retard. Je suis mordu de C++, j'aime le coté template, mais je crois qu'avec le recul on a appris à faire mieux, et que boost n'est là que pour tenter de rendre le C++ immortel au coup d'une complexité non justifié.

Pour finir je trouve que Qt apporte beaucoup plus au C++. Mais je pense que de toutes manières le C++ est dépassé, et que cela pourrait ouvrir un débat sur le futur du C++. Et tout cela sans vouloir troller

[shenron666]

C'est pas faux. C'est comme ça qu'on se retrouve avec encore des projets en Visual 6

évites de sortir mes propos de leur contexte en ne me citant pas entièrement

quand une lib est mise à jour on regarde les raison de la mise à jour et si c'est utile/important on fait la mise à jour
sinon, on garde une version stable et on s'y tient

---

Aussi pour ce qui est thread, mutex, je trouve mieux fait ce que propose Qt ou encore ce que j'ai recodé moi même que ce que propose boost à ce sujet.

déjà comparer boost et Qt, faut oser
mais dire que les threads/mutex de Qt sont mieux que boost c'est ton avis, le miens est totalement contre Qt

[firebird_dev]

déjà comparer boost et Qt, faut oser
mais dire que les threads/mutex de Qt sont mieux que boost c'est ton avis, le miens est totalement contre Qt

Ils ont une partie commune que l'on peut comparer. Ils n'adoptent pas la même philosophie après. Mais je ne compare pas les deux dans leur globalité.

Ça m'intéresse de savoir pourquoi ton avis est contre Qt à ce propos ?

[3DArchi]

concernant les mise à jour, ça ne sert à rien de suivre le projet comme un petit chien, on prend une version, on prend les libs qui nous sont utiles, quand une lib est mise à jour on regarde les raison de la mise à jour et si c'est utile/important on fait la mise à jour
sinon, on garde une version stable et on s'y tient

C'est pas faux. C'est comme ça qu'on se retrouve avec encore des projets en Visual 6

[shenron666]

Ça m'intéresse de savoir pourquoi ton avis est contre Qt à ce propos ?

je ne suis pas contre Qt, je préfère ceux de boost
je trouve leur utilisation plus pratique
en même temps, ça fait un moment que j'ai pas touché à Qt donc si ça se trouve ça a changé

3DArchi > tu préfère un projet VC6 terminé dans les temps ou un projet VC2008 qui en est à son 666ème rework ?

[Goten]

Ils ont une partie commune que l'on peut comparer. Ils n'adoptent pas la même philosophie après. Mais je ne compare pas les deux dans leur globalité.

Ça m'intéresse de savoir pourquoi ton avis est contre Qt à ce propos ?

C'est Qt qui souffre de NIH (historique) pas le contraire.

[JolyLoic]

De plus il existe un conflit par exemple avec le define signals de boost et de Qt (enfin ça c'était il y a 3 ans, maintenant je ne sais pas si c'est toujours un soucis).

Ça, c'est clairement un problème de Qt, qu'aucune autre bibliothèque ne peut corriger à leur place... Ils ont utilisé un #define, qui plus est sur un mot d'emploi courant, qui leak en dehors de leurs headers. Ils ont un peu amélioré ça (http://www.boost.org/doc/libs/1_46_1...gnals/s04.html), mais franchement, ils cherchent les ennuis en l'occurence...

[bjbjb]

Je trouve que boost est plus un phénomène de mode qu'autre chose.
Certes il apporte beaucoup à l'évolution du C++, et notamment en rajoutant le plus important dans tr1 et C++0x (C++1x n'existant plus comme nom pour la remarque).

Il exploite complètement la métaprogrammation. Et j'ai un avis très mitigé à propos de la métaprogrammation. Parfois cela est génial, parfois c'est une horreur. Et dans ce cas là une librairie comme Qt me parait 100x plus clair et légère d'utilisation.

Je ne peux pas être plus d'accord avec firebird_dev.
La métaprogrammation ça peut rendre le code tellement illisible.

Quand il compare, QT et Boost, je le soutiens parce que ce sont 2 frameworks et il compare leur philosophie et en ceci elles sont comparables.

Nous n'utilisons sur notre projet que la métaprogrammation de boost et c'est pour cela que cela devient très long, le processeur travaille énormément et ne peut pas être remplacé par des libs.

Mais, il est vrai que le projet sur lequel nous travaillons est énorme.
(10ans - 30 personnes)

[Klaim]

Boost n'est pas un framework. Le comparer a Qt est comme comparer un porte-avion et un sous marin sous prétexte qu'ils naviguent tous les deux en mer. Ca n'emêche pas qu'ils ne sont pas directement comparable : la seule chose que tu peux comparer c'est la difference entre leurs objectifs.

Qt est un framework alors il représente une forme d'environnement.

Boost est un set de bibliothèques. Dans l'idéal on devrait pouvoir juste piocher des biliothèque qui nous interessent dans le "label" boost. Ils ne forment pas un environnement, même si ils fournissent de quoi s'en faire un.

Qt est fait pour les applications visuelles. Boost est généric. Etc.

Je sais même pas pourquoi on parle de Qt là, c'est assez hors sujet... POCO est plus proche de l'idée de Boost que Qt!

[Goten]

Je sais même pas pourquoi on parle de Qt là, c'est assez hors sujet...!

+1.

Pas parce que Qt se sent obligé de fournir un QVariant que c'est la même chose que boost :'.

[r0d]

Ben c'est pas évident. Je suis d'accord que Qt et boost n'ont pas le même objectif, mais ils ont tout de même pas mal de choses en commun (les signaux, le système de fichier, un module réseau, les threads, ...).

Après évidemment, les objectifs et la philosophie (donc les paradigmes utilisés) sont très différentes. D'un côté Qt, qui est plus unifié, utilise beaucoup l'héritage (avec son QObject notamment), et de l'autre, boost qui est plus modulaire, utilise fortement les templates, et donc les traits, politique et allocateurs.

Je pense donc que l'on peut les comparer sur certains points (par exemple, on peut comparer certaines choses entre un sous-marin et un porte-avion), mais pas de façon générale.

[Luc Hermitte]

Et on en revient à un ancien débat sur l'héritage depuis void*^Wune classe objet racine.
boost est un ensemble hétérogène de bibliothèques qui se veulent compléter le standard, et qui donc verra certaines de ses parties disparaitre éventuellement -- sauf si failles/compléments trouvés. On peut à la rigueur voir boost devenir une sorte de STLport pour la partie TR1.
Qt se veut autonome, donc il réinvente tout (*), même certains trucs qui ont pris du temps à arriver dans les implémentations du standard. Nous ne sommes pas prêts de voir disparaitre ses containers COW malgré l'avènement des rvalue-references. Même dans 10 ans quand les projets auront majoritairement migré, Qt aura gardé son approche COW.
(*) À ce compte là on peut comparer Qt à tout.

[3DArchi]

Et on en revient à un ancien débat sur l'héritage depuis void*^Wune classe objet racine.

Pour les curieux : Que penser des frameworks et architectures qui font dériver toutes les classes d'un SuperObjet ?

Qt se veut autonome, donc il réinvente tout (*), même certains trucs qui ont pris du temps à arriver dans les implémentations du standard.

D'une certaine façon, rien n'empêcherait de faire des binding Qt vers d'autres langages (ancien Jambi, Python, .Net (?)) alors que pour boost, cela fait quand même beaucoup moins sens.

Même dans 10 ans quand les projets auront majoritairement migré

Quel bel optimisme

[Luc Hermitte]

Optimiste ? Moi?
Nostalgique! de VC 6, OK, je sors.

[r0d]

Sur ce genre de sujet, il faut être optimiste car c'est auto-opérant: plus on est nombreux à y croire, plus les décideurs vont penser qu'il faut le faire

[Goten]

Et on en revient à un ancien débat sur l'héritage depuis void*^Wune classe objet racine.
boost est un ensemble hétérogène de bibliothèques qui se veulent compléter le standard, et qui donc verra certaines de ses parties disparaitre éventuellement -- sauf si failles/compléments trouvés. On peut à la rigueur voir boost devenir une sorte de STLport pour la partie TR1.
Qt se veut autonome, donc il réinvente tout (*), même certains trucs qui ont pris du temps à arriver dans les implémentations du standard. Nous ne sommes pas prêts de voir disparaitre ses containers COW malgré l'avènement des rvalue-references. Même dans 10 ans quand les projets auront majoritairement migré, Qt aura gardé son approche COW.
(*) À ce compte là on peut comparer Qt à tout.

Gardé le COW, de nos jours... ça fait mal quand même.

[JolyLoic]

L'impression que j'en ai tiré la dernière fois que j'ai lu, c'est que ça permet aux gens n'ayant pas compris le passage par référence de ne pas plomber leurs perfs...

[Joel F]

Donc plombons les libs de fonctionnalités qui ne servent qu'a rendre les gens betes plus betes ...

Quant a l'aspect meta de boost, faut voir a pas tout melanger. La seule partie meta c'est dans les trucs genre mpl,proto,fusion et autres infrastructures. Le reste c'est de la prog generique et generative, qui n'a un bon rien a voir. Personnelement je trouve qu'un code generique (au sens de Stepanov) est mille fois plus lisible que du pseudo C avec de l'heritage et des pointeurs "parce que Robert de la compta, les references il comprends pas" justement car c'est extrement intentionnel et abstrait.

Apres couiner que boost soit casse pieds a installer alors que builder un truc Qt blinder de MOC et autres cochonenries de 1492 ... ca me fait rigoler ^^

[r0d]

J'adore ton sens du débat Joël
Je suis fan