Y a-t-il une raison de ne pas utiliser Boost ?

Question

J'ai eu cette discussion avec mon collègue aujourd'hui à propos de l'utilisation de Boost dans notre nouveau projet C++. Il n'était pas d'accord pour utiliser Boost car il pense que Boost est énorme et un autre point qu'il a ajouté est que pourquoi l'équipe de Chrome a choisi de ne pas utiliser Boost ? Je ne sais pas trop quoi répondre... Ce qu'il veut dire, c'est qu'aucun des projets C++ actuels n'utilise Boost, à part ses librairies comme SmartPointers.

J'aime utiliser Boost et j'adore coder en utilisant la bibliothèque Boost, mais je n'ai aucun argument pour prouver que Boost est le meilleur choix à utiliser dans n'importe quel projet C++ comme les applications de bureau ou les applications serveur.

Des idées ?

Answer 1

La question de savoir s'il faut "utiliser Boost" ou "ne pas utiliser Boost" est une fausse dichotomie. Boost est délibérément conçu pour avoir de nombreux composants, et relativement peu de dépendances entre eux. Si votre projet a besoin d'une fonctionnalité particulière de Boost, vous devez évaluer le composant en fonction de vos besoins et l'intégrer ou non au projet.

Si la question est "pourquoi les projets ne permettent-ils pas simplement d'utiliser l'ensemble de Boost comme s'il faisait partie des bibliothèques standard ?", la réponse est une discussion générale sur les raisons pour lesquelles un projet logiciel pourrait vouloir limiter ses dépendances au code non standard, et en particulier aux bibliothèques dont les APIs sont encore en développement. Certaines parties de Boost sont stables, d'autres non. Certains projets sont destinés à être ultra-portables, dans ce cas vous ne voulez généralement pas dépendre des bibliothèques Boost qui contiennent du code spécifique à une plateforme, car vous devrez alors forker Boost afin de le porter sur votre prochaine plateforme. Certains projets ne veulent pas d'un codeur isolé dans un coin utilisant Boost.Spirit alors que tout le monde crée ses parsers avec Bison. Et ainsi de suite.

Les pointeurs intelligents sont presque omniprésents parce que l'implémentation de Boost est (1) extrêmement utile, répondant à un besoin de nombreux projets ; (2) extrêmement portable ; (3) presque standard ( shared_ptr est dans TR1) ; (4) petit ; (5) recommandé par tous les experts, ce qui signifie que tous les programmeurs C++ le connaissent. Cela contrecarre presque toutes les raisons de ne pas l'utiliser. Mais tous les composants Boost ne possèdent pas toutes ces propriétés.

Un commentaire sur Chrome en particulier : il y a une très brève discussion sur Boost dans le guide de style C++ de Google. Google semble avoir des règles très strictes pour admettre les dépendances externes des bibliothèques C++. Je suppose que c'est parce que Google a de nombreux programmeurs et de nombreux produits, et que pour eux, l'économie de réinventer la roue en interne, pour répondre à leurs besoins précis, est différente de celle de la plupart des entreprises. Google peut se permettre de bien inventer des choses et de les utiliser beaucoup, alors que la plupart des entreprises sont beaucoup plus petites et doivent faire moins de choses pour les faire bien. Ainsi, par exemple, Google peut se permettre de maintenir son propre navigateur, sa propre boîte à outils d'interface utilisateur Web (GWT), sa propre technologie de serveur (MapReduce, GFS) et de construire lui-même des centres de données à partir de processeurs et de bouts de ficelle. Même si je déteste le langage marketing, la plupart des entreprises doivent se concentrer sur leurs compétences de base et ne pas se lancer dans des activités à la fois verticales et horizontales.

Vous ne pouvez donc pas nécessairement utiliser Google comme un exemple de pourquoi ne pas utiliser Boost, à moins que vous ne soyez également prêt à l'utiliser comme un exemple de pourquoi ne pas acheter des cartes mères de base. Cela ne veut pas dire qu'il n'y a pas de nombreuses raisons pour lesquelles votre projet pourrait vouloir éviter une bibliothèque donnée, ou que votre entreprise ne peut pas avoir confiance en sa capacité à faire avancer les choses. Mais il y a de fortes chances que les raisons invoquées par Google ne s'appliquent pas à vous et que les choses que vous ferez ne seront pas celles que fait Google.

Answer 2

Toutes les réponses précédentes mises à part, c'est généralement une énorme perte de temps si vous n'utilisez pas Boost si et où vous le pouvez. Vous devriez en effet réfléchir aux parties de Boost à utiliser, en fonction de plusieurs critères mentionnés précédemment, mais le rejeter d'emblée est une approche non professionnelle et révèle le manque d'expérience de la personne.

Besoin d'un analyseur syntaxique ? Vous avez besoin de contrôler la gestion de la mémoire (par exemple, shared_ptr) ? Besoin d'un cadre indépendant du système d'exploitation, avec threading, gestion des fichiers et plus encore ? Besoin de verrouillage et de synchronisation ? Besoin de performances ? Vous avez besoin de structures de données solides ? Tout est là, et plus encore. Et ça marche. Réinventer tout cela par vous-même est une perte de temps, donc coûteux et, à mon avis, tout simplement stupide.

Il y a des raisons légitimes de ne pas utiliser Boost. Si le compilateur de votre choix n'est pas supporté par Boost, vous êtes grillé. Si vous avez des solutions alternatives pour les parties de Boost que vous allez probablement utiliser, et que vous êtes plus familier avec le codage de ces solutions, alors allez-y et réussissez. Si vous détestez les erreurs de compilation et d'édition de liens terriblement illisibles que vous obtenez parfois avec Boost, c'est compréhensible. Mais si vous n'utilisez pas Boost parce que l'équipe de quelqu'un d'autre ne l'a pas utilisé non plus, vous avez oublié de penser par vous-même. Boost est trop précieux pour être mis de côté aveuglément.

Answer 3

À ma grande honte, je pense que j'ai peut-être été comme votre collègue il y a quelques années - j'étais très sceptique au début quant aux avantages réels que l'on pouvait tirer d'un tel programme. booster pourrait fournir. Je l'ai aussi vu comme un énorme monstre monolithique qui ne servait pas à grand-chose, à part une classe utile occasionnelle.

Heureusement pour moi, j'ai fini par être convaincu que nous avions vraiment besoin d'un coup de pouce et que nous trouverions finalement plus d'avantages à mesure que nous comprendrions mieux la bibliothèque.

Quelques points à prendre en compte pour tenter de convaincre votre collègue :

1. Boost est assez volumineux, mais l'installation elle-même est conservée soigneusement dans un seul répertoire.
2. L'installation ne doit se faire qu'une seule fois (ce qui, à mon avis, n'est pas vraiment un obstacle majeur).
3. Vous commencerez progressivement à utiliser de plus en plus de fonctionnalités dans boost au fur et à mesure que vous apprendrez à connaître le framework et la façon dont il peut améliorer votre code de production.
4. La qualité du code est très élevée - des personnes bien plus intelligentes que moi maintiennent le boost et s'assurent que les bogues sont minimes et que les performances sont optimales.
5. Les bibliothèques CRT/MFC/Qt sont assez importantes - je suis sûr qu'il n'envisagerait pas d'écrire du code sans ces frameworks ! ;)

Answer 4

Eh bien, vous avez beaucoup d'arguments en faveur du boost :

Si votre patron prétend qu'il ne peut pas l'utiliser en raison de problèmes de licence, vous pourriez copier la licence de Boost, qui est vraiment claire et objective, et lui demander où elle n'est pas claire ?

S'il dit qu'il est difficile de trouver des gens qui comprennent la STL, et encore plus difficile pour Boost, vous pourriez dire qu'il a probablement raison, mais, il est beaucoup plus facile d'apprendre Boost que la STL, même plus, la documentation de Boost est extrêmement bonne, et ont beaucoup d'exemples. Boost est beaucoup plus facile à apprendre que beaucoup de bibliothèques comme MFC, ATL, STL, QT. Ainsi, on pourrait dire que quiconque connaît MFC, ATL, STL ou QT, serait capable de se familiariser rapidement avec Boost.

S'il dit que le boost n'est pas standardisé, demandez-lui de regarder le code boost. Tout le code suit les mêmes directives, les mêmes directives de STL. De plus, la majorité des membres du comité de boost font également partie de la norme C++. Et le TR1 est implémenté dans Boost.

S'il dit qu'il est difficile de distribuer Boost ou qu'il faut s'assurer que le client a la bonne version, vous pouvez simplement dire que vous utiliserez l'outil "bcp". BCP est un outil boost, utilisé pour copier tout le code dépendant de boost directement dans votre application, ainsi, votre application n'utilisera que les fichiers boost qu'elle utilise.

S'il dit que le boost prendrait beaucoup de temps à apprendre, vous pourriez dire que le boost vous ferait gagner beaucoup de temps en vous évitant de réinventer la roue. De plus, il est très difficile d'utiliser Boost de manière incorrecte, ce qui oblige à une bonne qualité du code.

Je ne demanderais probablement pas si je peux utiliser le boost, je l'utiliserais tout simplement. J'ai fait cela plusieurs fois, et les gens que je connaissais qui seraient contre, l'ont apprécié par la suite, d'abord parce qu'ils pouvaient comprendre le code, et la qualité était élevée grâce à l'utilisation des tests unitaires de boost, et il n'y avait presque pas de bugs.

Mais, dans votre cas, votre patron a déjà dit NON. Il ne sait probablement pas comment programmer, mais vous pourriez essayer de passer un accord, comme par exemple, utiliser seulement les bibliothèques boost qui sont dans TR1, et ne pas utiliser l'espace de noms boost, en utilisant l'espace de noms std::tr1 à la place. Ce sera de toute façon dans la prochaine norme C++. Et s'il dit non, vous pouvez simplement utiliser BCP, pour copier les en-têtes dans le répertoire de votre application, et les utiliser comme std::tr1 dans votre code, et lui dire que vous n'utilisez que l'implémentation boost tr1, et s'il n'aime pas, il peut acheter un tr1, ou encore mieux, lui demander de vous laisser développer toutes les classes en tr1, cela vous prendra beaucoup de temps, mais ce sera certainement très amusant :)

Vous avez appris une leçon, ne demandez pas, utilisez-le. Les gens ont habituellement peur de ce qu'ils ne connaissent pas.

Answer 5

Il souffre probablement du syndrome "Pas inventé ici". Dès qu'il commence à réinventer quelque chose dans le boost, faites-lui remarquer.