Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par r0d

123PARTAGES

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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de JolyLoic
Rédacteur/Modérateur https://www.developpez.com
Le 23/03/2011 à 15:46
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...)
9  0 
Avatar de Joel F
Membre chevronné https://www.developpez.com
Le 02/04/2011 à 12:36
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 ^^
8  0 
Avatar de Klaim
Membre expert https://www.developpez.com
Le 31/03/2011 à 1:22
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!
6  0 
Avatar de jblecanard
Membre expert https://www.developpez.com
Le 23/03/2011 à 17:10
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 Voir le message
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 Voir le message
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 Voir le message
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 Voir le message
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 Voir le message
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...
3  0 
Avatar de Flob90
Membre expert https://www.developpez.com
Le 23/03/2011 à 18:38
Bonjour,


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.


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.


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).
3  0 
Avatar de JolyLoic
Rédacteur/Modérateur https://www.developpez.com
Le 30/03/2011 à 15:04
Citation Envoyé par firebird_dev Voir le message

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...
3  0 
Avatar de Joel F
Membre chevronné https://www.developpez.com
Le 03/04/2011 à 14:10
Citation Envoyé par r0d Voir le message
J'adore ton sens du débat Joël
Je suis fan
et encore, je reste soft .

Plus serieusement, c'est comme tout. Boost est un outil. On l'utilise si besoin voila. Apres, entendre pleurer des gens comme quoi il arrive pas a decoller leur tapisserie avec un pistolet a clou ... bon
3  0 
Avatar de 3DArchi
Rédacteur https://www.developpez.com
Le 24/03/2011 à 7:34
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.
2  0 
Avatar de r0d
Expert éminent https://www.developpez.com
Le 24/03/2011 à 11:58
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.
2  0 
Avatar de 3DArchi
Rédacteur https://www.developpez.com
Le 24/03/2011 à 12:57
Citation Envoyé par r0d Voir le message

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 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 Voir le message
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.
2  0