Donc, si vous passez du temps à regarder / répondre aux questions sur Stack Overflow sous la balise C ++, vous remarquerez rapidement que presque tout le monde utilise la bibliothèque boost ; certains diront même que si vous ne l'utilisez pas, vous n'écrivez pas du "vrai" C ++ (je ne suis pas d'accord, mais ce n'est pas le propos).
Mais il y a ensuite l'industrie du jeu, qui est bien connue pour utiliser C ++ et non pour utiliser boost. Je ne peux pas m'empêcher de me demander pourquoi. Je ne me soucie pas d’utiliser boost parce que j’écris (à présent) comme un passe-temps, et une partie de ce passe-temps consiste à mettre en oeuvre ce dont j'ai besoin quand je le peux et à utiliser des bibliothèques standard lorsque je ne le peux pas. Mais c'est juste moi.
Pourquoi les développeurs de jeux, en général, n'utilisent-ils pas la bibliothèque boost? Est-ce une question de performance ou de mémoire? Style? Autre chose?
J'étais sur le point de poser cette question lors d'un débordement de pile, mais je me suis dit que la question était mieux posée ici.
MODIFIER :
Je me rends compte que je ne peux pas parler pour tous les programmeurs de jeux et que je n'ai pas vu tous les projets de jeux, je ne peux donc pas dire que les développeurs de jeux n'utilisent jamais boost; c'est simplement mon expérience.
Permettez-moi de modifier ma question pour demander également, si vous utilisez boost, pourquoi avez-vous choisi de l'utiliser?
Réponses:
Certains développeurs en ont, d'autres non (dans les jeux et ailleurs). Cela dépend des besoins / exigences de ces développeurs et de la technologie existante à exploiter.
Bibliothèque standard de C ++ est souvent donné le même traitement, et les gens se demandent souvent la même chose que vous vous interrogez sur ce , aussi. La plupart des raisons sont similaires, par exemple:
Un développeur peut déjà disposer d'une bibliothèque de fonctionnalités interne fournissant les mêmes services que la bibliothèque standard ou Boost. De telles bibliothèques internes ont souvent été écrites il y a longtemps, lorsque le support d'implémentation de la bibliothèque standard était faible et que Boost était pratiquement inexistant, il a donc fallu les écrire plus ou moins . Dans ce scénario, il n’est généralement pas utile de s’éloigner de la fonctionnalité interne: c’est un effort de transfert important qui déstabiliserait beaucoup de code et ne procurerait pratiquement aucun avantage.
Un développeur peut travailler sur des plates-formes où la prise en charge par le compilateur des techniques C ++ avancées exploitées par Boost n'est pas bien prise en charge, de sorte que le code Boost ne compile pas du tout ou fonctionne assez mal. Ceci s'applique également à la bibliothèque standard, bien que beaucoup moins de nos jours.
Boost et la bibliothèque standard du langage ont une utilité générale, et même si cela convient à la plupart des applications, un développeur a parfois des besoins spécifiques qui peuvent être mieux pris en charge par des conteneurs plus spécialisés.
Je pense que ce qui précède sont deux raisons raisonnables, bien qu’il y en ait certainement d’autres. Vous devez cependant faire attention, car de nombreuses raisons pour éviter Boost, les bibliothèques standard, ou tout ce qui en découle, se résument à un syndrome "pas inventé ici", ce qui peut indiquer que la raison n'est pas très bien fondée sur les réalités pratiques.
Rappelez-vous également que les besoins d'un studio de grande taille sont généralement très différents de ceux d'un développeur individuel. Par exemple, un développeur individuel a probablement moins de code hérité à gérer et donc le transfert depuis une version locale de la fonctionnalité Boost ou de la bibliothèque standard ne sera pas aussi long et vous éviterez que ce développeur ait à maintenir ce code aussi largement dans le futur - invalidant ainsi mon premier point.
En fin de compte, il s’agit d’évaluer vos besoins et votre temps de travail par rapport à votre objectif souhaité et de déterminer quelle option répond le mieux à vos besoins. Les développeurs qui n'utilisent ni Boost ni la bibliothèque standard l'ont généralement fait et sont parvenus à cette conclusion - vous le ferez peut-être aussi, et peut-être pas.
la source
Modifier Revenant à cette question après quelques années
Ayant continué à utiliser de plus en plus de bibliothèques boost, j'ai pensé mettre à jour cette question afin de vous expliquer pourquoi vous devriez utiliser boost lorsque la description du produit correspond à la fonctionnalité souhaitée. Cela convaincra même les non-sayeurs. Téléchargez openSSL et essayez de créer une application cliente et serveur. Maintenant, essayez de faire en sorte que cela fonctionne sur toutes les plateformes. Ensuite, téléchargez et utilisez boost :: asio :: ssl pour créer la même application. Si vous n'êtes pas convaincu que boost constitue le bon endroit pour rechercher du code multiplateforme propre, bien optimisé, examiné par les pairs, cet exercice simple vous convertira.
Tl; dr version:
À mon avis, vous ne voyez pas une tonne d'entreprises de développement indépendantes ou de petite à moyenne taille utiliser boost, car c'est une bête sauvage massive et puissante qui n'est pas facile à apprivoiser et vous êtes fondamentalement autonome lorsque vous essayez d'apprendre comment pour l'utiliser. La documentation manque de plusieurs manières (voir version longue) et "la communauté" autour du projet semble manquer, être dispersée ou être inactive (par rapport à d'autres projets).
Version très longue:
je me rends compte qu'il existe déjà une réponse acceptée, mais en tant que personne qui utilise réellement boost dans presque tous les projets que je fais, je pensais poster une réponse.
Je me souviens de la première fois où je me suis mis à bricoler et honnêtement, je ne savais absolument pas ce qui se passait. Boost n'est pas très bien documenté du tout. Les gens pourraient être en désaccord avec moi sur ce point, j'en suis sûr, car il y a des tonnes d'extraits de code d'exemple et de commentaires, etc., mais c'est très froid et vague, de même qu'il est difficile de s'y retrouver.
En outre, il semble difficile de trouver un endroit où vous sentez que vous avez trouvé "la communauté" autour du projet. En fait, la communauté semble inexistante ou nomade. Malheureusement, même leur liste de diffusion a été suivie par tellement de sites de sangsues que vous pouvez vous rendre dans ce terrier de lapin toujours en boucle.
Ces deux facteurs rendent l’apprentissage de l’utilisation des librairies boost plus difficile. Même si les aspects techniques de l'utilisation de boost ne sont pas excessivement complexes, il s'agit d'un ensemble considérable de bibliothèques que vous ne pouvez armer que lorsque vous ne possédez que quelques fragments de code et des éléments éparpillés de la liste de diffusion des coins les plus sombres d'Internet. ... bien vous avez l'idée.
J'ai commencé à bricoler avec boost autour de la version 1.45 et ce n'est que maintenant dans la version 1.52 / 1.53 que je me sens assez à l'aise pour l'utiliser en production. Il y a tellement de choses auxquelles il faut s'habituer et dont on se souvient, même des choses simples comme la configuration et l'optimisation de la configuration, car la manière dont les bibliothèques sont construites et leur fonctionnement peut varier énormément en fonction de vos préférences au moment de la compilation, en raison de la personnalisation des éléments. sont.
Cependant , ne vous y méprenez pas , une fois que vous pouvez utiliser le boost, vous avez acquis une arme puissante pour créer rapidement des programmes multi-plateformes solides. Il suffit de prendre
boost::asiopar exemple. Vous pouvez écrire un serveur Web asynchrone multi-plates-formes immensément puissant, évolutif et solide en quelques centaines de lignes. Au fil des ans, j'ai écrit plusieurs clients, serveurs, serveurs mandataires, etc., avec seulement quelques centaines de lignes de code qui ne m'ont pas encore échoué, et je peux les porter d'une plateforme à l'autre en quelques minutes.Comme d'autres l'ont fait remarquer, les grandes entreprises sont généralement confrontées à des problèmes hérités ou aiment se lancer, ce que je comprends parfaitement. Il y a aussi cette chose vraiment stupide dont j'ai entendu parler et que j'ai rencontrée là où le développeur mène et / ou les chefs de projet interdisent d'utiliser boost parce que c'est "trop grand". J'imagine qu'ils croient qu'il s'agit d'une seule bibliothèque ou qu'ils n'ont jamais entendu parler du PCA .
Quant à POURQUOI je choisis d’utiliser boost
Je dirais que je l'utilise parce que, comme vous l'indiquez dans votre question, c'est "la" bibliothèque C ++. Dans le monde C ++, Boost est considéré comme le couteau suisse que vous devrez utiliser par la suite. L'idée est donc que s'il y avait un besoin, il devrait y avoir une version très performante et portable dans boost. Les grandes entreprises contribuent à stimuler , les personnes très instruites avec des CV impressionnants le maintiennent et, quand une nouvelle norme C ++ est en cours de développement, les gens cherchent généralement à savoir quelles parties de celle-ci devraient devenir C ++ normalisé ISO.
Donc, si j’ai besoin d’ajouter des fonctionnalités pour lesquelles il existe probablement une bibliothèque, le premier endroit que je regarderai, c’est boost, car je suis assez sûr de parier que c’est plutôt bien optimisé, portable, elle sera supportée et maintenue pendant très longtemps et les bugs seront trouvés et traités. Dans le monde open source, ces qualités peuvent être très difficiles à trouver.
la source
Nous avons utilisé un peu de Boost sur notre ancien lieu de travail. Les principales raisons pour l’éviter et limiter son utilisation étaient les suivantes:
la source
La même chose est (était?) Être dit pour le "plus standard" STL. Cet article parle d'EASTL, une réécriture interne de (parties de) STL par Electronic Arts pour répondre aux besoins du développement de jeux assez différents de ceux du développement d'applications "plus génériques".
Alors, peut-être que quelqu'un quelque part est en train de réécrire (des parties de) boost pour répondre à leurs besoins en développement de jeux!
la source
Qui a dit qu'ils n'utilisaient pas de boost? J'ai connu un ou deux moteurs C ++ utilisant boost. Je n'ai jamais travaillé directement avec eux. mais c'est surtout parce que mon expérience réside dans Unreal.
En ce qui concerne les raisons que j'ai rencontrées pour ne pas utiliser boost, et celles-ci sont subjectives:
En gros, il s’agit: une solution générale n’est pas toujours la solution idéale.
Je suis sûr que quelqu'un qui a réellement travaillé avec la bibliothèque pourrait mieux commenter.
la source
Je traîne à StackOverflow et n'utilise pas de boost. J'ajouterai ma raison, car c'est une raison qui n'a pas encore été mentionnée.
Boost a beaucoup de bonnes idées, vraiment. J'aime regarder ce qu'ils ont fait et essayer de nouvelles choses et idées. C’est formidable, car c’est un terrain fertile pour de nombreuses améliorations de C ++.
Mais le coup de pouce est une bête très difficile à manier pour de nombreuses raisons. Une des raisons est qu’ils ont besoin (veulent) d’être compatibles avec pratiquement tous les compilateurs, avec toutes les bizarreries. En conséquence, ils doivent employer de nombreuses astuces, telles que MPL pour réussir. Par exemple (il y a longtemps), je voulais utiliser leur shared_ptr. Pour l'exécuter, il me fallait les sources et les bibliothèques de ce qui semblait être 90% de boost. J'ai fini par écrire le mien; 50 lignes de code lisibles. (Mes exigences étaient plus strictes, pas de sécurité faible ni de thread.)
Souvent, vous avez besoin d'un très petit sous-ensemble de boost, mais intégrer l'intégralité du boost ne vaut tout simplement pas la peine.
Modifier :
Juste pour préciser est clair, car il semble ne pas être venu clairement (c-à-d. Vote négatif). J'utilise n'utiliser les bibliothèques de tiers. Mais dans la plupart des cas, toutes choses étant égales par ailleurs, en intégrant une bibliothèque tierce ou un boost, l’autre bibliothèque tierce est plus rapide et plus propre. Le reste est fait en "2h". Je jette un regard très dur dans la question de la construction ou de l’achat.
la source
Dans notre cas (pas les jeux), nous avons une bonne raison de ne pas utiliser boost (ni std): Nous avons beaucoup de code qui remonte à une décennie. Selon les seniors, std et boost étaient soit incomplets, pleins de bugs, soit tout simplement trop lents pour les performances exigeantes. Certaines classes de base ont donc été implémentées, en utilisant les mêmes concepts (tels que les itérateurs) et souvent optimisées pour nos algorithmes. De nos jours, les trois bibliothèques (la nôtre, std et boost) sont très similaires.
Mais voulons-nous porter sur tout notre code? Pas vraiment. Je suppose que beaucoup d'autres entreprises font face au même dilemme. Soit réécrire beaucoup de code testé et fonctionnel ou ne pas utiliser std / boost.
la source
Personnellement, je n'utilise ni boost ni aucun autre code à usage général lors de la création de jeux, car les jeux ne sont généralement pas à usage général. Le type de code dont vous pourriez avoir besoin pour implémenter un jeu est généralement spécifique au développement de jeux, pas toujours, mais comme 98% (valeur aléatoire) du temps. Vous pouvez vous en tenir aux derniers morceaux de code provenant de boost ou d’une autre bibliothèque, mais c’est probablement mieux de simplement écrire le petit morceau dont vous avez besoin ici et là.
Sur une note de côté, je pense que c'est plutôt amusant d'écrire votre propre code en c ++, c'est pourquoi je n'ai jamais utilisé boost ou quoi que ce soit du genre.
la source
l'héritage des bibliothèques maison n'est pas un facteur ... la principale raison pour laquelle personne ne devrait utiliser boost u autre bibliothèque à usage général est parce qu'elles ne sont pas optimisées en termes de vitesse et de mémoire, même si je dois mentionner que Cryengine utilise la STL mais qu'elles compilent il s'agit d'une version open source appelée STLPort, alors n'ayez pas peur d'utiliser la STL, implémentez simplement vos allocateurs personnalisés et tout ira bien. n'utilisez pas de boost tho.
la source