La STL (Standard Template Library) forme une composante essentielle du C++. Parties de recherches sur la programmation générique indépendantes du C++, elles se sont greffées à celui-ci jusqu'à en devenir une partie du standard.

La STL offre, en vrac, des conteneurs (listes, tableaux, tableaux associatifs,...), des algorithmes génériques (comme le tri), des flux (fichiers) et j'en passe.

Quel bonheur pour le programmeur de ne plus avoir à implémenter pour la nième fois une liste chaînée. Ou bien, s'il en avait une dans sa trousse à outils, quel bonheur de pouvoir se reposer sur une interface standardisée.

l’extension de la disponibilité d'implémentation de STL sur différentes plateformes et différent compilateurs a créé des remous. Parmi ces remous, il a les signes du faux Graal (lien) : adhésion totale,opposition, rejets. Dans les exemples que je connais, heureusement,la dernière phase a été atteinte : utilisation raisonnée.

Quel est le problème de la STL ? Il y en a des généraux et des plus particuliers.

Dans les généraux, le premier auquel fait face le programmeur est le debug des conteneurs. Les implémentations STLs sont généralement efficace et pour cela utilisent des structures de donnees pas toujours simples à suivre. De plus, la programmation étant générique et les débuggeurs pas forcément à la hauteur, il n'est pas toujours aisé de s'y retrouver.

Par exemple, trouver le 10ieme element d'une liste de pointeur.

Sur ce point, les débuggueurs ont fait des progrès, mais c'est un point qui a rangé une génération de programmeur dans le camp de ceux qui ne veulent (ou voulaient) plus entendre parler de la STL.

Toujours dans les généraux et voisin du précédent : comprendre le code d'une implémentation STL n'est pas aisé. Pour une raison ou une autre, les implémentations STL aiment les noms de variables membres courts, parfois limité à un tiret bas suivi d'une lettre.La programmation étant générique, il est fait usage de typedefs qui, eux-meme, n'ont pas toujours des noms tres clairs.

Ca n'a l'air de rien, mais en production, ces deux premiers points ont pu faire perdre pas mal de temps aux enthousiastes initiaux de la STL qui avaient pensé y trouver leur Graal.

Mais finalement, ces points sont surmontables : debugger en semi-aveugle est une tâche classique (même si elle n'est pas agréable) et comprendre une implémentation se travaille et s'acquiert.

Il y a-t-il d'autres griefs ? Oui.

Dans le domaine que je connais le mieux, il y a de gros soucis pour faire tourner un programme en production avec la STL. Ces soucis sont nombreux et largement décrit dans l'excellent article EASTL.La plupart se résument à un manque de contrôle sur les allocations faites par la STL. Dans un environment tel qu'un ordinateur personnel de bureau,ce n'est pas trop un problème : le système d'exploitation est là pour gérer la mémoire et il le fait généralement bien.

Dans des systèmes plus petits (systèmes embarqués ou consoles de jeu par exemple) la mémoire est une denrée précieuse et chère. Dans ce genre de projets, il y a eu ceux qui n'ont jamais voulu entendre parler de la STL (souvent ceux qui n'ont auparavant jamais voulu entendre parler du C++) et ceux qui l'ont intégrée.

Au final, une intégration de la STL dans ces produits qui veulent maîtriser la mémoire se retrouve en grande partie dans les outils externes au produit ou avec des implementations, comme l'EASTL, dimensionnée pour ces plateformes.

À ceux qui, arrivés ici, pensent que je n'aime pas la STL et que cet article la dénigre, je demanderai de revenir sur l'introduction (lien)de cet article ainsi qu'à son titre.

La STL est un très très bon outil. Mais sa valeur est double alors que,souvent, une seule des deux est utilisée. Sa première valeur, la plus flagrante, est d'offrir au C++ des outils qui sont utilisés plus que fréquemment, pour ne pas dire sur n'importe quel projet. Sa seconde valeur, moins souvent perçue, est d'avoir offert au C++ un ensemble d'interfaces standardisés.

Ces interfaces permettent d'ajouter aux STL ses propres conteneurs,algorithmes génériques ou de manière générale, ses propres outils,tout en gardant une cohérence globale, une bonne lisibilité (et donc un abord facilité pour le nouveau venu sur le projet) et un bon interfaçage avec d'autres outils.

C'est sur cette force que repose d'ailleurs Boost, qui offre un ensemble d'outils dont certains ont été acceptés pour la prochaine version de la norme C++. Ces outils sont cohérents avec le reste du standard.

Cette approche \"à la Boost\" (qui ne veut rien dire d'autre que \"cohérente\")est utilisée par d'autres projets (Asio).

La STL n'est pas le Graal : elle résous de nombreux cas, fait gagner du temps de développement sur certaines applications. Mais son utilisation doit être raisonnée : elle ne résous pas TOUS les problèmes et ne convient pas à TOUTES les applications. Le croire amène des déceptions qui peuvent amener à occulter ses qualités.