Discussion :

[r0d]

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.

[JolyLoic]

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

[jblecanard]

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.

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.

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.

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

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.

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

[Flob90]

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

[3DArchi]

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.

[r0d]

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.

[3DArchi]

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

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.

[Drannor]

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

[Firwen]

Boost est clairement excellent, et bien plus "C++ oriented" que Qt par exemple ( et c'est un utilisateur de Qt qui dit ça ).
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.

[Klaim]

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.

[Klaim]

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.

[barmic]

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.

[Luc Hermitte]

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

[Je hais le système de quote de dvpz ]
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.

[yostane]

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.

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

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

++

[bjbjb]

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

[yostane]

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.

[jblecanard]

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.

[Joel F]

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

[shenron666]

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