Boost : Bibliothèque indispensable ou phénomène de mode ? Peut-on, doit-on s'en passer ?

Bonjour tout le monde,

note: je créé ce sujet pour éviter de polluer une autre discussion.

Alors voilà, ça fait plus de 10 ans que je programme intensément en c++. J'utilise boost dans quasiment tout mes projets.

Mais, je persiste à dire que, sauf dans le cas particulier de l'apprentissage du langage, boost c'est comme les pointeurs: il ne faut l'utiliser que si l'on ne peut pas faire autrement.

Tout d'abord, l'installation est lourde. Si on installe tout, ça peut prendre plus de 3Go. Donc, outre le fait que c'est lourd, cela peut poser des problèmes de transport etc. Par exemple, moi j'aime bien me promener avec une clé usb sur laquelle j'ai des projets persos. Ce n'est évidemment pas possible d'avoir les différentes versions de boost utilisées par mes projets sur ma clé usb.

Ensuite, boost est une lib, pour ainsi dire, constamment en travaux. Et les testeurs ce sont nous. Je comprend bien les raisons de cette situation, mais c'est parfois assez enervant. Par exemple, j'ai constemment des problèmes de portabilité avec boost. Jamais de gros problèmes insurmontables, mais c'est toujours ennuyeux de modifier son source juste (auquel on a réfléchi, choisi telles solutions, etc.) juste pour un problème de portabilité.

Autre chose, c'est que boost n'est pas toujours facile à utiliser, et parfois il fait perdre plus de temps que ce qu'il nous en fait gagner. J'ai personnellement vécu une très mauvaise expérience avec boost::graph (je crois que maintenant c'est mieux, mais il y a 2-3 ans c'était l'enfer à utiliser, et j'ai fini par implémenter mon propre graphe et ses algos).

Enfin, mais cette critique est commune à toutes les libs, l'utilisation d'une lib externe peut poser problème lorsqu'on change de contexte (changement d'ordinateur, d'os, etc.). Le poids de boost et son évolution rapide ne facilitant pas la chose.

Je ne parlerai pas de la documentation, car ça fait longtemps que je n'y ai pas jeté un coup d'oeil, et j'ai ouïe dire que ça s'est nettement amélioré.

Pour finir, je trouve que beaucoup des choses qui sont dans boost ne sont pas indispensables, et bien souvent il est préférable de faire notre propre code, qui sera plus adapté à notre contexte et plus facile à optimiser. Car ce qui prend le plus de temps dans notre métier, ce n'est pas l'écriture du code, mais l'organisation du programme.

Voilà, c'est mon point de vue, et je suis curieux de voir comment vous allez démonter mes arguments. Mais je tiens à insister sur 2 points: Je suis bien conscient que boost

1. est gratuit, open source, que ses contributeurs sont bénévoles, etc.

2. implémente plein de choses géniales et souvent très utiles, voire indispensables. Par exemple, j'aurai maintenant du mal à me passer de boost::bind et boost::function, même s'il est possible de faire autrement.

Mais ces 2 points ne nous empêchent pas de critiquer constructivement le produit.

Je considère difficile de parler de boost comme un seul truc, et je prendrais des décisions bibliothèque par bibliothèque, pas globalement.

Pour tout développement, si une bibliothèque dans boost répond aux besoins spécifiques, je la considèrerais quand même comme un candidat sérieux à évaluer.

Est-ce que boost est un must-include pour tout projet en C++ ? Il y a 7 ans, j'aurais dit oui sans hésiter. Désormais, les parties de boost que je considère comme absolument indispensables pour n’importe quelle application font partie de TR1 et C++0x (shared_ptr, bind, function...)

Je suis vraiment d'accord avec JolyLoic sur le fait qu'on ne peut pas juger Boost dans son ensemble global.

Je suis d'accord avec certains arguments de r0d et pas trop avec d'autres, voici mon avis, qui n'engage que mon expérience personnelle, bien entendu, qui n'a pas 10 ans d'ailleurs, mais est plus courte.

Citation:

---

Envoyé par r0d

Tout d'abord, l'installation est lourde. Si on installe tout, ça peut prendre plus de 3Go. Donc, outre le fait que c'est lourd, cela peut poser des problèmes de transport etc. Par exemple, moi j'aime bien me promener avec une clé usb sur laquelle j'ai des projets persos. Ce n'est évidemment pas possible d'avoir les différentes versions de boost utilisées par mes projets sur ma clé usb.

---

Ca je suis d'accord que c'est chiant, mais ce genre de maintenance arrive nécessairement dans un projet conséquent qui ne peux pas se reposer que sur du code "in house" et sur la STL. Et je suis d'accord qu'il y a des progrès à faire sur la facilité d'installation. L'installateur de Boostpro rend bien service mais ce n'est pas encore la panacée.

En revanche, le concept de promener ses projets, ça ne peux poser que des problèmes à un développeur. Une machine de dev nécessite forcément de la configuration, de l'install... Boost ou pas, je ne peux pas me promener d'une machine à l'autre avec une simple clé USB, j'ai besoin de trop de logiciels pour travailler.

Donc pour moi : d'accord mais ce n'est pas lié intrinsèquement à Boost, donc c'est un peu injuste de le lui mettre sur le dos.

Citation:

---

Envoyé par r0d

Ensuite, boost est une lib, pour ainsi dire, constamment en travaux. Et les testeurs ce sont nous. Je comprend bien les raisons de cette situation, mais c'est parfois assez enervant. Par exemple, j'ai constemment des problèmes de portabilité avec boost. Jamais de gros problèmes insurmontables, mais c'est toujours ennuyeux de modifier son source juste (auquel on a réfléchi, choisi telles solutions, etc.) juste pour un problème de portabilité.

---

Jamais eu le problème perso, c'est pour ça qu'il y a des versions stable et non stables... à moins d'utiliser les nouveautés "borderline", je n'ai jamais rencontré ce problème.

Citation:

---

Envoyé par r0d

Autre chose, c'est que boost n'est pas toujours facile à utiliser, et parfois il fait perdre plus de temps que ce qu'il nous en fait gagner. J'ai personnellement vécu une très mauvaise expérience avec boost::graph

---

C'est vrai pour les grosses machines comme Boost.Graph mais on ne peut vraiment pas mettre Bind, Function, les smart pointers dans ce panier là...

Citation:

---

Envoyé par r0d

Je ne parlerai pas de la documentation, car ça fait longtemps que je n'y ai pas jeté un coup d'oeil, et j'ai ouïe dire que ça s'est nettement amélioré.

---

Oui elle est vraiment pas mal maintenant, mais encore une fois, ça dépend de la lib.

Citation:

---

Envoyé par r0d

bien souvent il est préférable de faire notre propre code, qui sera plus adapté à notre contexte et plus facile à optimiser.

---

Là par contre, je ne suis carrément pas d'accord, car justement, le fait que le code soit beaucoup utilisé par d'autres le rend nécessairement plus robuste et plus performant. Les concepteurs se sont largement brisé le crâne pour éviter à d'autres de le faire. Boost me fait gagner énormément de temps de ce point de vue. Je ne m'en sers pas si je n'en ai pas besoin, mais dès que je rencontre un besoin implémenté par Boost dans les libs "classiques", je n'hésite pas une seconde...


Ma conclusion : un installateur qui permet de sélectionner quelles parties de Boost on veut télécharger et installer, en gardant la possibilité de rajouter une lib sur une installation existante, est vraiment quelque chose qui manque. Les utilitaires comme program_options ou filesystem sont fort utiles et ne sont pas dans TR1...

Bonjour,

Citation:

---

Mais, je persiste à dire que, sauf dans le cas particulier de l'apprentissage du langage, boost c'est comme les pointeurs: il ne faut l'utiliser que si l'on ne peut pas faire autrement.

---

Pour ce point là, avec l'arrivé du C++1x sur les compilateurs ca va être accentué. Car si aujourd'hui certains prefèrent utiliser les futures outils du C++ en passant par boost, ca sera surment moins le cas dans quelques temps, et c'est quand même bien ces outils là qui sont les plus utilisés dans boost, le reste sont des outils qui répondent à des besoins plus spécifiques.

Citation:

---

Autre chose, c'est que boost n'est pas toujours facile à utiliser, et parfois il fait perdre plus de temps que ce qu'il nous en fait gagner. J'ai personnellement vécu une très mauvaise expérience avec boost::graph (je crois que maintenant c'est mieux, mais il y a 2-3 ans c'était l'enfer à utiliser, et j'ai fini par implémenter mon propre graphe et ses algos).

---

J'ai toujours un peu de mal à prendre en main quelque chose proposé par boost quand je le découvre, une fois pris en main je trouve que la doc est suffisament clair, mais pas dans un premier temps. Et la découverte de Poco ne fait que renforcer chez moi l'idée que boost est relativement complexe à prendre en main.

Citation:

---

Pour finir, je trouve que beaucoup des choses qui sont dans boost ne sont pas indispensables, et bien souvent il est préférable de faire notre propre code, qui sera plus adapté à notre contexte et plus facile à optimiser. Car ce qui prend le plus de temps dans notre métier, ce n'est pas l'écriture du code, mais l'organisation du programme.

---

A part ce qui est passé de boost à C++1x, c'est vraie que le reste est plus spécifique. Ceci dit, certaines des libs de boost sont si spécifiques que si j'en ai besoin je ne les réécrirais pas, pour deux raisons : le code n'est pas si simple, et ce que je ferais ne sera pas plus perfoment même dans mon contexte (je pense à Proto par exemple).

Salut,

La fréquence des mises à jour est parfois ce qui peut me faire hésiter avant d'intégrer une bibliothèque Boost. Sur certains projets longs, la stabilité des bibliothèques est un indicateur. Et la migration parfois pas trivial (quelques traumatismes Boost.Spirit). Maintenant, il est vrai que beaucoup de bibliothèques du corpus boost n'ont pas bouger depuis longtemps.

Effectivement, beaucoup des bibliothèques boost les + utiles sont sur TR1 ou C++0x. Ce qui rend leur utilisation dans boost moins pertinente. Mais il existe encore des compilateurs ne supportant pas TR1/C++0x et pour lesquels il faut s'appuyer sur Boost.

Il y a des choses pour lesquels repartir from scratch consiste en un travail colossal (boost.mpl par expl ou boost.preprocessor) même si on ne les utilise qu'à 10% de leur possibilité.

Après, il faut faire attention au syndrome NIH.

Merci pour vos commentaires, c'est très intéressant tout ça.

Je voulais ajouter une petite remarque, en deux points.
1. Dans ma branche (informatique industrielle disons), on a souvent des petits programmes à faire. On ne travaille pas que sur des gros projets. Donc par exemple, si je dois programmer un petit démon qui manipule des fichiers, qui fait 200 lignes de code genre, qui nécessite un fichier de configuration simple, et que je dois implémenter chez le client sur un serveur qui n'a pas boost d'installé (situation assez récurrente dans mon cas personnel), je ne pense pas qu'il soit nécessaire d'installer boost juste pour avoir boost.options.
2. Beaucoup de gens qui postent ici, sur developpez.com, sont des étudiants ou sont des programmeurs débutants qui n'interviennet pas encore sur des gros projets critiques et doivent écrire des petits programmes. Pour ces gens-là, boost ne me parait être systématiquement une bonne solution. Je leur conseille tout de même de l'utiliser, car c'est du beau code et c'est l'avenir du c++, mais pas systématiquement.

Citation:

---

Envoyé par r0d

Je voulais ajouter une petite remarque, en deux points.
1. Dans ma branche (informatique industrielle disons), on a souvent des petits programmes à faire. On ne travaille pas que sur des gros projets. Donc par exemple, si je dois programmer un petit démon qui manipule des fichiers, qui fait 200 lignes de code genre, qui nécessite un fichier de configuration simple, et que je dois implémenter chez le client sur un serveur qui n'a pas boost d'installé (situation assez récurrente dans mon cas personnel), je ne pense pas qu'il soit nécessaire d'installer boost juste pour avoir boost.options.

---

Et donc tu n'utilises pas la STL mais définis tes vecteurs avec des allocations dynamiques et tes chaînes de caractères à la C :aie: Tout ça pour dire qu'installer Boost peut pour beaucoup de bibliothèque se résumer à dézipper les sources. Donc pas très couteux en terme de déploiement chez ton client

Citation:

---

Envoyé par r0d

2. Beaucoup de gens qui postent ici, sur developpez.com, sont des étudiants ou sont des programmeurs débutants qui n'interviennet pas encore sur des gros projets critiques et doivent écrire des petits programmes. Pour ces gens-là, boost ne me parait être systématiquement une bonne solution. Je leur conseille tout de même de l'utiliser, car c'est du beau code et c'est l'avenir du c++, mais pas systématiquement.

---

Ca a aussi comme démarche d'apprendre à chercher les choses existantes plutôt que de systématiquement les refaire (mal en général), de faire connaître Boost et enfin son utilisation amène à se poser la question sur sa façon de développer en C++ et donc d'aller vers des pratiques plus robustes. L'utilisation de boost a aussi une vertu pédagogique.

J'ai une question :
Quel est l'avantage de Boost par rapport à une librairie comme POCO ?

Boost est clairement excellent, et bien plus "C++ oriented" que Qt par exemple ( et c'est un utilisateur de Qt qui dit ça :mrgreen: ).
Boost est même a mon sens indispensable, il accompagne C++ et le fait évoluer avec lui.

Deux gros cotés rebutants que je lui reprocherai :
- La doc fait peur pour un débutant, ça s'ameliore mais c'est loin du niveau de Qt.
- L'installation sous un OS sans repositories manager est, disons le franchement : chiante.

Il y a des plans qui sont en cours pour décomposer boosts en plusieurs versions ou ensembles ou je ne sais quoi.

Il est définitivement difficile d'en parler comme d'une seule librarie. Pour moi, c'est un label (de qualité), rien d'autre. D'ailleurs, il y a des cas ou des libraries non-boost sont plus efficace, notemment parceque les performances sont la seconde et non la première priorité de boost.

Autrement, je l'utilise généralement comme une STL++ mais seulement sur mes machines personnelles, et je met boost accessible dans l'environnement, pas dans le projet.

Maintenant il y a un mirroir git de boost, et je pense que je vais peut être utiliser la fonctionalité de subrepo de mercurial pour intégrer boost seulement aux projets qui en ont besoin. Bon en fait tous mes projets en on besoin mais juste ceux cross platform ou je veux que mes colllegues aient directement tout ce qu'il faut sous la main quand ils récupèrent le projet. Auquel cas, avoir un repo par libraries de boost serait encore mieu, mais ce n'est aps encore en place. Le projet Ryppl ( http://ryppl.org ) devrait aider de ce coté là, quand il sera stable.

Citation:

---

Quel est l'avantage de Boost par rapport à une librairie comme POCO ?

---

Simplement, boost a plus de libraries, donc si POCO te suffit, il n'y a pas d'avantages.
Cela dit, certaines bibliothèques de boost aliées a d'autres bibliothèques de POCO ou de Qt marchent très bien. C'est pour ça que c'est difficile de parler de "bibliothèque boost".

Personnellement je met boost dans l'environnement et toutes les autres libraries je les met dans les repos de mes projets, sous un dossier de dépendances.

Je connais boost depuis pas mal de temps, mais je n'avais jamais eu à m'en servir jusqu'à il y a une semaine. J'ai surtout utilisé uBLAS pour avoir des matrices et toutes les méthodes qui vont avec sans soucis (j'ai aussi utilisé les vec_ptr vraiment cool quand on manipule de gros objets). J'ai trouvé la documentation relativement utilisable (il manque juste un peu d'organisation).

Par contre deux jours après j'ai découvers eigen, qui permet entre autre le calcul de valeurs propres et là il n'y a pas photo. C'est plus agréable à utiliser (le seul problème c'est qu'il n'est pas forcément simple de savoir quel est le type que renvoie une fonction). Le temps de compilation est augmenté de beaucoup, mais par contre je n'ai pas vu d'impact sur les temps d'execution (ce ne sont pas les calculs sur les matrices qui prennent le plus de temps).

Je pense encore que pas mal de leurs bibliothèques sont excellentes, mais il ne faut pas pour autant oublier d'aller voir ailleurs comment ça se passe.

Citation:

---

Envoyé par 3DArchi

Citation:

---

Envoyé par r0d

1. Dans ma branche (informatique industrielle disons), on a souvent des petits programmes à faire. On ne travaille pas que sur des gros projets. Donc par exemple, si je dois programmer un petit démon qui manipule des fichiers, qui fait 200 lignes de code genre, qui nécessite un fichier de configuration simple, et que je dois implémenter chez le client sur un serveur qui n'a pas boost d'installé (situation assez récurrente dans mon cas personnel), je ne pense pas qu'il soit nécessaire d'installer boost juste pour avoir boost.options.

---

Et donc tu n'utilises pas la STL mais définis tes vecteurs avec des allocations dynamiques et tes chaînes de caractères à la C :aie: Tout ça pour dire qu'installer Boost peut pour beaucoup de bibliothèque se résumer à dézipper les sources. Donc pas très couteux en terme de déploiement chez ton client

---

[Je hais le système de quote de dvpz :evilred:]
J'utilise des morceaux de boost quand je peux, mais d'autres ... non. Typiquement, dernièrement, je n'ai pas hésité une seule seconde avant de partir sur du tclap (.sf.net) (un pour de mauvaises expériences passées avec program_options à qui il manquait des fonctionnalités, et qui était resté avec une doc obsolète trop longtemps ; deux pour tester cet autre COTS). Et pour les fichiers .rc de conf, j'ai ma lib efficace que je me réécris de tête à chaque fois (clients différents). Oui, c'est pénible.

Je fais aussi de l'industriel. Et souvent, ce qui m'empêche d'exploiter boost, ce sont des compilos obsolètes (là, c'est g++ 2.95.x sur une saleté d'ARM qui ne connait pas les compteurs atomiques) qui font qu'on ne peut s'en servir dans la globalité, ou quand on est chanceux juste par morceaux.

Pour ce qui est de développer chez le client, il faut souvent faire valider les COTS par les chefs de projet & cie. On ne fait pas toujours ce que l'on voudrait.

Au contraire, c'est un avantage que le librairie soit lourde, ça prouve qu'elle offre beaucoup de fonctionnalités. En plus, il est possible de ne prendre que les librairies qui nous intéressent.
Les mises à jour fréquentes ne me dérangent pas non plus, ça prouve une autre fois que c'est une bonne lib qui est bien maintenue.

C'est peut-être un peu hors sujet, mais à tous ceux qui utilisent Boost,
je leur conseille de jeter un œil à Poco :
http://pocoproject.org/

Plus récentes que Boost, ces librairies se veulent plus user-friendly et ont atteintes un excellent niveau de stabilité (jamais rencontré un seul bug avec les versions stables). Elles sont bien sûr gratuites et open-source (Boost software licence). Les domaines pris en charge sont assez vastes :
Ptr, Dynamic, Any, Net, Zip, Xml, Crypto, Logger, Time, Events, File, Framework, etc...

J'en profite aussi pour rebondir sur les problèmes de portabilité évoqués plus haut. J'ai personnellement buildé et utilisé Poco sous Windows, Ubuntu et plusieurs plateformes Linux embarqués (les dernières news parlent d'ailleurs d'une compatibilité iPhone et Android).

Niveau installation, tout les scripts et les projets sont présents pour builder chaque lib (quelques Mo seulement) en static/dynamique, debug/release (difficile de faire plus simple).

Bref, j'arrête de faire la pub gratuite, mais je pense que tout bon développeur C++ devrait, à défaut de les utiliser, connaitre ces librairies ;)

++

Je crois que nous sommes tous d'accord. Boost est bien écrit et est très utile.

Toutefois, je travaille actuellement sur un énorme projet vieux d'une dizaine d'année qui repose sur une grosse partie de boost.

Les anciens architectes (si on peut les qualifier d'architectes) ont utilisés comme des petits fous Boost, le système est devenu très long à compiler, les templates de Boost (spécialement, spirit, bind et function ) sont absolument partout, et puis function a ses propres limites et on s'est retrouvé coincé dans ces limites..

Mon bémol, les templates, il faut les utiliser avec parcimonie, quand on a réellement besoin et de prendre soin de bien encapsuler son usage.

Et même,tous ces outils et facilités de langage comme le future Cx01 sont un plus à avoir mais j'essaye de toujours privilégier la solution la plus simple et peut-être moins fun mais qui marche...

Quand je pense à la quantité softs de qualités industriel qui ont été écrit qu'en C (Linux etc..).

Excusez-moi d'être un vieux rochon


PS:

Je vous donne un excellent lien sur les delegates en C++
http://www.codeproject.com/KB/cpp/FastDelegate.aspx

C'est fascinant de comparer son implémentation avec Boost::function

Citation:

---

Envoyé par GAujay

C'est peut-être un peu hors sujet, mais à tous ceux qui utilisent Boost,
je leur conseille de jeter un œil à Poco :
http://pocoproject.org/
++

---

Je l'ai déjà tresté pour générer du XML et elle est assez bien. Mais boost offre bien plus de fonctionnalités.

Je ne l'avais pas mentionné dans mon précédent post, mais je dois reconnaître que le temps de compilation supplémentaire nécessaire du fait de l'usage "lourd" des templates est un point un peu douloureux.

on fait pas d'omelette sans .. pardon on fait pas de programmation generique sans templates a un moment donné :o

Quant au temps de compilation, je susi toujours stupéfait du defaitisme a ce sujet. En general, je considere le temps de compilation comme une chose a optimiser aussi et dieux sait si y a moyen (split en TU séparé, pre-instanciation, pch etc).

Quant au perfs ou aux features manquant, patches welcome aussi :o

je pense également qu'on ne peux pas prendre boost pour une bibliothèque dans son ensemble
de mon point de vue, ne pas utiliser certaines parties de boost implique souvent de réinventer la roue

donc oui il faut utiliser boost quand on peut, mais ce serait arrogant envers boost de dire qu'on ne peut pas s'en passer

quand à la lourdeur, que ce soit la taille de boost ou sa fréquence de mise à jour, non je ne suis pas d'accord
j'ai du mal à imaginer un projet où on utilise boost dans son intégralité, impossible pour moi

on prend boost, on compile, on utilise les parties qui nous sont utiles et puis c'est tout, ça ne sert à rien d'intégrer boost entièrement
et puis les lib compilées ne prennent pas tant de place que ça

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

Citation:

---

Envoyé par shenron666

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 :aie:

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 :aie:

Citation:

---

Envoyé par 3DArchi

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

---

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

Citation:

---

Envoyé par shenron666

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

---

---

Citation:

---

Envoyé par firebird_dev

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

Citation:

---

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 ?

Citation:

---

Envoyé par shenron666

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 :aie:

Citation:

---

Envoyé par firebird_dev

Ç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é :aie:

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

Citation:

---

Envoyé par firebird_dev

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.

Citation:

---

Envoyé par firebird_dev

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

Citation:

---

Envoyé par 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.

---

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)

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!

Citation:

---

Envoyé par Klaim

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

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.

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.

Citation:

---

Envoyé par Luc Hermitte

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 ?

Citation:

---

Envoyé par Luc Hermitte

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.

Citation:

---

Envoyé par Luc Hermitte

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

---

Quel bel optimisme :mouarf:

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

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 ;)

Citation:

---

Envoyé par 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.

---

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

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

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

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