Augmenter la dépendance pour un projet open source C ++?

Question

Boost est censé être la bibliothèque standard C ++ non standard que chaque utilisateur C ++ peut utiliser. Est-il raisonnable de supposer qu'il est disponible pour un projet C ++ open source, ou s'agit-il d'une dépendance trop importante?

Answer 1

En gros, votre question se résume à la question suivante: "est-il raisonnable d’avoir [free library xyz] comme dépendance d’un projet open source C ++?"

Considérons maintenant la citation suivante de Stroustrup et la réponse est vraiment évidente:

  

Sans une bonne bibliothèque, les tâches les plus intéressantes sont difficiles à effectuer dans   C ++; mais avec une bonne bibliothèque, presque n'importe quelle tâche peut être rendue facile

En supposant que cela soit correct (et d'après mon expérience, ce soit le cas), écrire un projet C ++ de taille raisonnable sans dépendances est tout à fait déraisonnable.

En développant cet argument plus en détail, la dépendance une C ++ (hormis les bibliothèques système) que l’on peut raisonnablement espérer sur le système client (du développeur) est constituée par les bibliothèques Boost. Je sais que ce n’est pas le cas, mais ce n’est pas une présomption déraisonnable pour un logiciel.

Si un logiciel ne peut même pas compter sur Boost, il ne peut pas compter sur toutes les bibliothèques .

Answer 2

Consultez http://www.boost.org/doc/tools.html . Plus précisément, l'utilitaire bcp serait très utile si vous souhaitez intégrer vos dépendances renforcées à votre projet. Un extrait du site web:

"L'utilitaire bcp est un outil permettant d'extraire des sous-ensembles de Boost. Il est utile pour les auteurs de Boost qui souhaitent distribuer leur bibliothèque séparément de Boost et pour les utilisateurs de Boost qui souhaitent distribuer un sous-ensemble de Boost avec leur application.

bcp peut également indiquer sur quelles parties de Boost votre code dépend et quelles licences sont utilisées par ces dépendances. "

Bien sûr, cela pourrait avoir certains inconvénients - mais au moins, vous devriez être conscient de la possibilité de le faire.

Answer 3

J'avais l'habitude d'être extrêmement prudent en introduisant des dépendances dans les systèmes, mais maintenant, je constate que les dépendances ne sont pas un gros problème. Les systèmes d'exploitation modernes sont livrés avec des gestionnaires de packages capables de résoudre automatiquement les dépendances ou, du moins, d'aider les administrateurs à installer très facilement les outils nécessaires. Par exemple, Boost est disponible sous Gentoo-Postage en tant que dev-libs / boost et sous les ports FreeBSD en tant que devel / boost.

Les logiciels open source modernes reposent beaucoup sur d’autres systèmes. Dans une étude récente , en suivant les dépendances des paquets FreeBSD, nous avons établi que les 12 357 paquets de ports de notre système FreeBSD 4.11 avaient au total 21 135 dépendances de bibliothèques; c'est-à-dire qu'ils avaient besoin d'une bibliothèque, autre que les 52 bibliothèques faisant partie du système de base, pour pouvoir compiler. Les dépendances de bibliothèque comprenaient 688 bibliothèques différentes, tandis que le nombre de bibliothèques externes utilisées par un projet unique variait entre 1 et 38, avec une valeur de mode de 2. En outre, 5 117 projets utilisaient au moins une bibliothèque externe et 405 projets utilisaient 10 ou plus. .

En fin de compte, la réponse à votre question proviendra d’une analyse coûts-avantages. L’avantage de réutiliser une bibliothèque mature, largement utilisée, examinée et testée, telle que Boost, est-il supérieur au coût faible et décroissant d’une dépendance? Pour toute utilisation non-triviale des installations de Boost, la réponse est que vous devriez aller de l'avant et utiliser Boost.

Answer 4

Cela dépend. Si vous utilisez un modèle de classe défini dans le fichier d'en-tête uniquement dans Boost, alors oui, utilisez-le, car il n'aspire aucune bibliothèque partagée Boost, car tout le code est généré à la compilation, sans dépendance externe. Les problèmes de versions sont une douleur pour toutes les bibliothèques c ++ partagées, et Boost n’est pas à l’abri de cela, donc si vous pouvez éviter le problème, c’est une bonne chose.

Answer 5

KDE dépend également de Boost.

Cependant, cela dépend principalement de vos objectifs, et plus encore de votre public cible, plutôt que de la portée de votre projet. Par exemple, TinyJSON (très petit projet), représente presque 100% de Boost, mais c'est très bien car l'API fournie est similaire à Boost et est destinée aux programmeurs Boost qui ont besoin de liaisons JSON. Cependant, de nombreuses autres bibliothèques JSON n'utilisent pas Boost car elles ciblent d'autres publics.

Par contre, je ne peux pas utiliser Boost au travail et je sais que de nombreux autres développeurs (dans leur travail quotidien) sont dans le même bateau. Donc, je suppose que vous pourriez dire si votre cible est OpenSource et un groupe qui utilise Boost, allez-y. Si vous ciblez une entreprise, réfléchissez-y et copiez-collez uniquement les éléments nécessaires de Boost (et engagez-vous à les soutenir) pour que votre projet fonctionne.

• Modifier: Nous ne pouvons pas l'utiliser au travail parce que notre logiciel a être portable à environ 7 différents plates-formes et à travers 4 compilateurs. Alors nous ne pouvons pas utiliser boost parce qu'il n'a pas prouvé être compatible avec tous nos objectifs, donc la raison est un un technique. (Nous sommes d'accord avec le Partie OpenSource et Licence Boost, comme nous utilisons Boost pour d'autres choses à fois)

Answer 6

Les avantages de l'utilisation de boost lors de l'écriture de code C ++ sont nettement supérieurs à la complexité supplémentaire liée à la distribution du code open source.

Je travaille sur le Bloc-notes du programmeur et le code dépend du boost pour le test, les pointeurs intelligents et l'intégration python. . Il y a eu quelques plaintes à cause de l'exigence, mais la plupart d'entre elles vont continuer si elles veulent travailler sur le code. Prendre la dépendance est une décision que je n’ai jamais regrettée.

Pour alléger un peu la complexité des autres, j’inclus des bibliothèques prédéfinies versionnées pour le python renforcé, de sorte qu’il leur suffit de fournir une amélioration dans leurs répertoires d’inclusion.

Answer 7

Je dirais oui. Les deux Mandriva ( Red Hat ) et Ubuntu ( Debian basés) ont des paquets pour les bibliothèques Boost.

Answer 8

Je pense que la vaste fonctionnalité fournie par Boost et, comme vous le dites, est la bibliothèque standard C ++ non standard, la justifie en tant que dépendance.

Answer 9

Malheureusement, oui, ils sont facilement disponibles pour Ubuntu, mais pour RHEL 4 & 5, je les ai presque toujours finis par les fabriquer en tarballs. Ce sont d’excellentes bibliothèques, vraiment très volumineuses, comme si vous utilisiez une pointe de rail lorsque vous n'avez parfois besoin que d'une punaise.

Answer 10

Tout dépend de la façon dont vous allez utiliser Boost. Comme l'a dit Diomidis, si vous souhaitez utiliser des installations non triviales de Boost, n'hésitez pas. L'utilisation des bibliothèques n'est pas un crime.

Bien sûr, beaucoup de gens préfèrent ne pas utiliser Boost, car introduire de nouvelles dépendances a toujours des inconvénients et des soucis supplémentaires, mais dans un projet open source ... à mon avis, il est même acceptable de les utiliser si voulez les apprendre ou améliorer vos compétences sur eux.