Est-il pratique d'abandonner STL dans le développement C ++? [fermé]

Je sais que dans certains domaines (industrie du jeu par exemple), la STL n'est pas recommandée. Ma question est donc: est-ce vraiment une bonne pratique de ne pas utiliser STL dans certains cas? Si oui, quelles sont les principales raisons de ne pas utiliser la STL C ++ moderne?

• Je ne peux penser qu'à une seule raison valable et c'est vraiment rare: difficile en temps réel. Beaucoup de choses dans la bibliothèque standard allouent de la mémoire en interne et ce n'est pas suffisamment déterministe pour les applications en temps réel difficiles, il faut donc les éviter. Ces applications sont généralement assez simples, bien qu'elles prennent un temps disproportionné à se développer en raison de l'examen et des tests très rigoureux.

• Je peux penser à une raison invalide, mais très courante: les développeurs qui ne comprennent pas la complexité de calcul, abusent de STL puis blâment la bibliothèque.

  STL est généralement plus rapide au moment de l'exécution que les solutions de style C avec des pointeurs de rappel ou les solutions basées sur le polymorphisme avec des méthodes virtuelles ( voir également le keynote de Bjarne Stroustrup ). Cependant, lorsque le développeur ne comprend pas les spécifications de complexité données et abuse de la bibliothèque en créant quelque chose comme un vecteur de vecteurs de certains objets complexes (en C ++ 11, ce n'est plus un problème, cependant!), Cause un problème de performances et se défend avec "vous voyez, les vecteurs sont plutôt lents", cela peut donner l'impression que la bibliothèque standard est lente. Et une fois que les managers ont une telle perception, cela peut vivre très longtemps dans l'organisation.

• De toute évidence, vous ne pouvez pas utiliser quoi que ce soit que la plateforme que vous ciblez ne prend pas en charge. Cependant, nous ciblons actuellement quatre plates-formes mobiles les plus courantes (Android, iOS, Bada et ancienne WinCE) et utilisons la bibliothèque standard et certaines parties de Boost sur chacune d'entre elles.

  Une grande partie de la bibliothèque standard n'était pas prise en charge par Microsoft au début de WinCE (les iostreams IIRC ne sont sortis qu'avec Visual Studio 2005), mais il était possible d'utiliser STLport bien avant cela. Et vous pouvez généralement obtenir cela pour compiler n'importe quoi. J'appellerais donc cette raison invalide également.

  D'ailleurs, pendant assez longtemps ce n'est pas "STL", mais la bibliothèque standard ANSI C ++. Il est défini par le même document standard qui définit la langue elle-même. Tout ce qui ne le prend pas en charge ne mérite pas vraiment d'être appelé C ++.

J'utilise STL et boost depuis de nombreuses années déjà. Si je voulais l'abandonner et utiliser mes outils personnalisés, la motivation serait:

1. Réduction du temps de compilation (75%). L'inclusion d'iostreams peut ajouter 1 million de lignes de code à votre module. Oui, les en-têtes précompilés aident beaucoup, mais cela ralentit toujours beaucoup la compilation dans les grands projets. À long terme, cela fait perdre beaucoup de temps à quiconque y travaille.
2. Performance. (25%) STL est écrit pour fonctionner de manière générale, mais vous pouvez optimiser vos structures pour qu'elles fonctionnent exactement comme vous le souhaitez. Par exemple, vous pourriez avoir une structure de données avec des millions de chaînes courtes. Il pourrait être beaucoup plus rapide d'utiliser une classe de chaînes personnalisée basée sur le principe de boost :: small_vector (petit vecteur local statique de données, allocation dynamique uniquement pour les chaînes plus grandes), ce type de modifications peut rendre les sections critiques de code beaucoup plus rapides.

Il y a une bonne raison valable de ne pas utiliser la bibliothèque de modèles standard C ++: l'une de vos plates-formes cibles n'en a pas d'implémentation entièrement conforme (ou pas d'implémentation du tout) et vous savez qu'elle n'en obtiendra pas dans les prochaines années.

Je ne connais pas la complexité (efficacité de l'implémentation) mais j'utilise largement les conteneurs et les chaînes Qt au lieu des std et ils fonctionnent très bien. Je trouve également l'implémentation Qt des ensembles et des listes plus facile à utiliser.

Ainsi, il peut être pratique d'abandonner la STL si vous pouvez utiliser une autre bibliothèque qui correspond à vos besoins.

Patrick a évoqué la raison de ne pas utiliser l'intégralité de la STL, à savoir que votre ou vos plateformes n'en ont pas.

Dans l'ensemble, je pense que la question est sans objet. Ce n'est généralement pas une décision tout ou rien, mais une question de choix. Vous pouvez bien décider d'utiliser les conteneurs et les algorithmes, mais décidez d'utiliser quelque chose en dehors de Std Lib pour les chaînes et les E / S.

Ce n'est pas pratique, à moins qu'il y ait une raison lourde de le faire. Certaines de ces raisons auxquelles je peux penser ne comprennent qu'une implémentation partielle ou manquante de STL (ou toute autre partie de la bibliothèque standard) ou une limitation des ressources (mémoire, vitesse du processeur, stockage, ...) que vous devez contourner rouler vos propres outils qui adhèrent à ce que vous devez accomplir.

Dans l'industrie du jeu, la plupart des studios (même plus petits dans une certaine mesure) ont leurs bibliothèques internes et implémentent de nombreuses parties de bibliothèque standard qui sont hautement adaptées à la plate-forme cible et, dans certains cas, ciblent engnie ou même le jeu lui-même. Autrement dit, lors du développement d'un jeu pour consoles, le matériel est très limité par les normes d'aujourd'hui. Il y a des milliers et des milliers de lignes d'assemblage artisanal pour une raison. Il est très important de minimiser toutes sortes d'empreintes de ressources dans votre code afin que le jeu s'exécute plus rapidement, ce qui permet plus de contenu dans le monde du jeu (ou un monde plus grand par exemple), ce qui, espérons-le, aboutit à un meilleur produit.

"Chaque jeu réussi commence par déployer votre propre implémentation de liste chaînée."