Discussion :

[Joel F]

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

[guillaume07]

Je me demande tout de même dans quelle mesure on peut sérieusement faire du c++ sans avoir recours à BOOST. Hors mis développement de niche qui ont leurs contraintes.
C'est un peu comme faire du C# sans utiliser le framework .Net
My 2 cents.

[Klaim]

Je me demande tout de même dans quelle mesure on peut sérieusement faire du c++ sans avoir recours à BOOST. Hors mis développement de niche qui ont leurs contraintes.

Sur 80% des matériels embarqués (qui n'étaient donc pas des smartphones) sur lesquels j'ai travaillé, utiliser boost et une partie de la STL était une très mauvaise idée.

C'est un peu comme faire du C# sans utiliser le framework .Net

Oui, mais parfois, la plateforme .NEt ne rentre pas dans la machine
Et c'est loin d'être de la niche.

Cela dit, sur un desktop, faut avoir de sacrées raisons pour ne pas utiliser boost.


Genre, avoir un équivalent qui est suffisant. Comme POCO.


Donc en fait si, c'est pas si mal de pas utiliser boost quand t'en as pas besoin. Sans vouloir paraitre contradictoir, c'est pourça que je l'ai dans mon environnement : quand je l'utilise' ça devient une dépendance, quand jel'utilise pas c'est que j'en ai juste pas besoin (ça arrive).

[guillaume07]

Cela dit, sur un desktop, faut avoir de sacrées raisons pour ne pas utiliser boost.
.

Mon intervention se résume avec cette phrase finalement

Donc toi tu conseils POCO + C++0x comme alternative/remplacement de Boost? j'ai regardé un peu le source... je suis pas prêt de céder Boost pour Poco!

[Klaim]

Non, ce que je dit c'est que comme boost n'est pas une bibliothèques mais plutot un label apposé à un ensemble de bibliothèques (et distribuées ensemble), il y a des fonctionalités que tu trouveras proposées par d'autre bibliothèques. Elles seront implémentées différemment et auront donc des avantages et inconvénients différents. Cela te permet donc de choisir le bon outil pour la bonne tache.

POCO propos des bibliothèques qui sont pour certaines semblable a ce qu'on trouve dans boost, mais avec un autre style. Donc, encore une fois, si ça suffit pour un projet spécifique, et que le style te va, tu as alors le choix entre poco, boost ou d'autres libs.

Tant que cette notion de "choisir les outils pour le projet, avec les contraintes du projet" est gardée, peu importe boost, quelque chose d'autre ou une solution raison.

Boost n'est pas un marteau. C'est une marque d'outils. Du bistouri au marteau-piqueur.

[aoyou]

Je déterre cette ancienne conversation pour apporter ma pierre à l'édifice.

Dans ma société, l'expérience de Boost a été un semi-échec. Pour préciser le contexte, nous travaillons dans un domaine industriel et nous développons des codes pour nos propres besoins. Peu importe le domaine exact, c'est essentiellement pour dire que nous ne sommes pas des informaticiens purs et durs, ce qui peut peut-être expliquer la suite.

Il y a plusieurs années, pour développer de nouveaux codes (pour information nous ne faisons pas de code critique), nous sommes partis de nouvelles bases fraîches qui passaient en particulier par l'introduction de Boost dans nos codes. Pour faire référence au titre de cette discussion, nous avons sûrement suivi le phénomène de mode.

Malheureusement, il faut bien dire que plusieurs années après, Boost nous convainc peu. Nous ne retrouvons pas dans Boost, qui se prétend être force d'idée pour les futures évolutions du C++, la puissance d'une librairie standard dans laquelle un utilisateur lambda peut se retrouver, impression que nous trouvons en Java ou en Python.

Pour expliquer un peu plus mon propos, voici le ressenti général. D'une part, OK, Boost on sent que c'est très bien pensé, on n'a aucun doute sur la compétence des gens qui le développent mais ça reste par moment encore trop théorique et pas assez pratique. D'autre part, mais qu'est que c'est compliqué à installer. Et ne parlons pas des librairies qui n'ont pas un nom constant (avec les mt, s, g, d, avec parfois la version du compilo et la version de la librairie). Ça peut paraître sympa comme ça mais à ne pas nommer comme les autres, eh bien c'est pénible.

L'expérience la plus cruelle a été celle du filesystem : prise de tête à la lecture de la documentation pour comprendre la raison de certaines fonctions voire la raison du nom de certaines fonctions et ils ont eu, de plus, le bon goût de supprimer une fonction entre deux versions. Ça été corrigé par la suite mais ça a suffi pour nous rendre amers.

Que se passe-t-il maintenant chez nous ?

Avec l'avènement du C++11, nous n'utilisons plus de Boost que les librairies TR1 (vive les shared pointers). Le static_assert est maintenant intégré dans le langage. Avec le temps, le foreach de boost va être remplacé par la nouvelle syntaxe for du langage. Et ainsi de suite...

Et pour le reste ? Eh bien POCO. C'est sûrement bien moins pensé mais c'est pensé pratique. Nous ressentons dans POCO une librairie qui a été pensée pour des besoins de tous les jours.

Ainsi, on retrouve par exemple dans POCO le moyen de créer un fichier temporaire. Chez Boost, on se pose encore des questions
http://boost.2283326.n4.nabble.com/a...td2611871.html
http://boost.2283326.n4.nabble.com/B...td2594627.html
En attendant, les utilisateurs attendent...

Toujours dans la librairie filesystem de POCO, il nous a suffi de lire les noms des méthodes pour comprendre à quoi elles servaient. Boost, nous nous posons encore des questions.

Et pour l'installation et les librairies, c'est très classique.

Pour conclure, nous utilisons ou utiliserons les bonnes idées de Boost quand elles sont ou seront intégrées dans la norme et autrement POCO pour son côté pratique, prise en main rapide. Nous avons peut-être vécu la seule mauvaise expérience d'utilisation de Boost mais nous trouvons dans POCO une librairie qui pallient aux carences de Boost et surtout qui répond à nos besoins, mais je dis bien nos besoins. Je peux comprendre qu'ici, certains ne peuvent se passer de Boost.

[Flob90]

Je suis assez d'accord avec toi sur le fait que l'utilisation de boost n'est pas toujours intuitive, contrairement à poco par exemple.

Cependant sur l'installation et les noms de fichiers je ne suis pas d'accord avec toi. L'installation est pas si difficile que ca, suffit de suivre bêtement le "Getting Start" sur le site de boost, si la plateforme est pas exotique ca va tout seul. Pour les noms de fichier, ca permet juste de choisir le mieux adapté à chaque besoin (statique, multithread).

J'ai pas vraiment vu plus de simplicité à installer poco que boost.

Et ces problèmes d'installation n'existent que sous windows en général, sous un Unix les choses sont simples en général (sous NetBSD, j'ai juste eu à faire un make/make install pour installer les deux par exemple).

[aoyou]

Attention, j'exprimais une expérience de groupe et pas qu'une expérience personnelle (référence au "d'accord avec toi").

Personnellement, je m'en sors avec l'installation mais ce nommage suffit pour paumer certains de mes collègues et du coup me faire perdre du temps. Il y a juste une chose qui me gave personnellement, et ce n'est effectivement propre qu'à Windows, c'est d'avoir la version dans le nom de la librairie mais bon ce n'est qu'un détail et si POCO faisait ainsi, je préférerais encore utiliser POCO.

Ensuite, comme tu le dis, pour Boost, il "suffit de suivre bêtement le "Getting Start" sur le site de boost". Certes, mais pour POCO, il n'y a rien à lire car c'est très classique.

Mais bon, s'il n'y avait eu que des problèmes d'installation, nous n'aurions pas changé pour POCO.

[JolyLoic]

Là où j'ai du mal à suivre, c'est que normalement, sous windows, on n'a pas à se préoccuper des noms des bibliothèques, puisque tout est géré par l'autolink.

[Klaim]

Même questionnement, mais pour être précis, l'autolink se fait avec MSVC. Peut être qu'ils utilisent mingw?

Toujours dans la librairie filesystem de POCO, il nous a suffi de lire les noms des méthodes pour comprendre à quoi elles servaient. Boost, nous nous posons encore des questions.

Voici les noms des fonctions de boost filesystem v3 (plusieurs versions récentes):

absolute
canonical
copy
copy_directory
copy_file
copy_symlink
create_directories
create_directory
create_hard_link
create_symlink
current_path
exists
equivalent
file_size
hard_link_count
initial_path
is_directory
is_empty
is_other
is_regular_file
is_symlink
last_write_time
read_symlink
remove
remove_all
rename
resize_file
space
status
status_known
symlink_status
system_complete
temp_directory_path <--
unique_path

Je ne suis pas un spécialiste des filesystem, et je n'ai appris comment marchait ceux des unix-like que depuis quelques années, mais sincèrement je ne vois pas ce qui n'est pas clair.

Dans la V2 il y avait quelques nommages non clairs comme "complete" au lieu de "absolute" dans la v3.

J'imagine que votre version n'est pas tout a fait récente et que vous avez fait face à des problèmes corrigés depuis?

[Luc Hermitte]

Je comprends le sentiment relativement à certaines libs qui donnent l'impression de chercher la maturité. Il y a du positif : ils ne s'acharnent pas avec des modèles qui peuvent s'avérer mauvais, mais cherchent au contraire où est la perfection.
Et dans un monde industriel où l'on cherche la stabilité, c'est sûr que c'est mal venu.

Pour les nommages, aujourd'hui je déteste les libs qui utilisent les mêmes noms (en particulier quand on n'a qu'un seul répertoire de sortie) pour tous les modes de compilation. C'est trop vite l'enfer quand on veut passer de l'une à l'autre.
En fin de compte je trouve le choix de boost très intelligent et bien plus pratique. Probablement que mes besoins de validation sont plus poussés que pour d'autres.

[aoyou]

C'est là qu'on voit que vous n'avez jamais dialogué avec mes collègues qui ne vont pas plonger plus d'un doigt dans la configuration logicielle si ça ne ressemble pas à ce qu'ils font d'habitude car l'important c'est d'implémenter des algorithmes et pas la merdouille autour à mon grand désarroi, je l'avoue par moment

Donc, que s'est-il passé pour l'autolink ? A partir du moment, où l'un d'entre nous est tombé sur un problème avec l'autolink, comme on peut le voir dans certaines discussions sur Google (chercher +boost +autolink +problem), eh bien, il est passé à la trappe. De plus, de toutes les librairies que nous utilisions, c'était la seule qui était en autolink (du moins par défaut). Alors, boost sans autolink comme pour les autres...

Ensuite, pour les noms des bibliothèques, il se trouvent que nous utilisons des scripts de configuration et build automatiques. Chacune des bibliothèques que nous utilisons sont classés dans des répertoires renseignant la version et le compilateur. Nos codes pointent ensuite vers une version courante de ces bibliothèques, acceptée et validée, et de temps en temps on fait évoluer cette version courante. Dans notre cas, mettre la version dans la librairie est redondant mais surtout amène une exception de traitement dans la configuration automatique. Les scripts de configuration cherchent la bibliothèque qui s'appellent bidule mais pas bidule-x.y.z. Bon, je vous rassure, on peut s'en sortir même avec des versions dans le nom mais comme toujours l'exception était Boost. Pour terminer sur le nom, nous faisons toutefois une exception pour les librairies en release et en debug avec effectivement un d, Debug ou ce que vous pourrez imaginer dans le nom de la librairie.

Juste un mot sur les scripts de build, nous les utilisons pour compiler la nuit, en debug, en release, avec valgrind, purify, gcov, sous Windows, Linux... Ce n'est donc par manque d'un besoin en validation poussée, tout au contraire.

Pour les fonctions de Boost filesystem, je pense qu'on me dirait : c'est quoi canonical, current_path, equivalent, initial_path, system_complete et à l'époque, on avait leaf, remove_leaf et branch_path. Alors qu'on s'attend à trouver working_directory, filename, dirname...

Je vois qu'il y a une petite flèche devant temp_directory_path. Le besoin qui avait été exprimé à l'époque était de créer un fichier temporaire qui disparaisse tout seul à la fin de l'exécution du programme (pour ne pas remplir le tmp avec des gros fichiers temporaires). temp_directory_path permet juste de pointer vers le tmp mais pas de répondre au besoin ci-dessus, ce que fait par contre POCO. C'est pour cela que je disais tout à l'heure que l'impression qui a été ressenti à l'arrivée de POCO était "Voilà enfin une bibliothèque qui répond à nos besoins de manière pratique car pensée par des gens qui doivent penser comme nous".

Au final, je pense que c'est toute une accumulation de petits désagréments qui a conduit à son rejet partiel. Si on devait retenter l'aventure maintenant, peut-être que ça se passerait autrement mais les rancœurs sont tenaces surtout quand on trouve mieux, mieux pour soi.

[Klaim]

Pour les fonctions de Boost filesystem, je pense qu'on me dirait : c'est quoi canonical, current_path, equivalent, initial_path, system_complete et à l'époque, on avait leaf, remove_leaf et branch_path. Alors qu'on s'attend à trouver working_directory, filename, dirname...

Concernant ce point, le souci d'utiliser des "working_directory" etc tels que tu les cites est problématique ou plutot "naif" si l'on a besoin de considérer les différents OS qui ne marchent pas tout a fait pareil, mmême si maintenant il y a enfin de la convergeance (ya un "home" sous windows maintenant).

J'imagine que le reste est question de connaissances sur les filesystems. Je vais tenter de décrire celles que tu cites selon mes connaissances sans regarder la doc voir ce que ça donne:

canonical : l'adresse cannonique, donc entière et certainement OS-spécific. Cela dit ca me parait peut être ambigu par rapport a absolute() (qui était complete() auparavant)

current_path: le path de travail courant (ton working_directory), qui peut avoir été changé au cours de l'application, d'ou la présence de...

initial_path: qui donne le path au démarrage de l'application.

equivalent: pas certain de savoir, faudrait que je vois la signature au moins, mais j'imagine que c'est pour vior si un path relatif et un path absolu pourraient coincider?

oups je dois partir, dsl