Discussion :

[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 ?

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

[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

[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

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