Est-ce que std :: string fait partie de la STL?

Question

^{(Quand je dis STL, je parle de la bibliothèque de modèles qui tourne autour de conteneurs, itérateurs, algorithmes et foncteurs.)}
Cette question est venue à l'esprit après avoir pensé qu'une std::string se comporte essentiellement comme un récipient normale, fonctions begin et end (y compris iterator), une fonction size et la possibilité d'utiliser tous ceux pour les algorithmes de STL normaux qui travaillent sur des conteneurs/gammes par leurs itérateurs (par exemple transform, sort, find, etc.).

Dans le même temps, cependant, ce n'est pas un conteneur lui-même, car il ne rentre pas dans l'image des conteneurs qui stockent des données arbitraires. En outre, il fonctionne sur les données contenues principalement à travers les fonctions membres, comme substr, find_first_of, etc., alors que le vrai conteneur ne le fait pas et laisse les algorithmes gérer cela.

En outre, le cplusplus reference site et la norme C++ ne répertorient pas std::string avec les conteneurs réels, mais dans une catégorie distincte.
Cependant, sur SGI's STL site, basic_string (et par conséquent le string typedef) sont mentionnés avec l'autre conteneur et le basic_string reference site indique qu'il appartient à la catégorie "conteneurs". Maintenant, ma question est: est-ce que string fait partie de la STL ou est-ce une bibliothèque distincte?
Et si elle appartient maintenant à la STL, est-ce qu'elle différait du STL original développé par Stepanov?

Answer 1

Non, pas vraiment. Et oui, en quelque sorte.

There are varying definitions of "the STL", dont:

• Le HP/SGI STL réelle, la bibliothèque d'origine, dont certaines parties de la bibliothèque standard C++ a été basée. Ils comprenaient des conteneurs, des itérateurs et des algorithmes. Les chaînes étaient et non une partie de cela.

• Les parties de la bibliothèque standard C++ basées sur la bibliothèque SGI STL: conteneurs, itérateurs et algorithmes. Toujours pas de chaînes.

• Toute la bibliothèque standard C++. Cette définition n'a absolument aucun fondement dans la logique ou la réalité bien que, si elle est suivie, std::string serait inclus.

Notez que la STL réelle a développé depuis C++ a été standardisé (il y a 13 ans, rappelez-vous), et ils ont adopté en arrière-certaines des choses qui est entré dans la norme, comme des chaînes. Cela ne signifie pas pas qu'ils étaient à l'origine là en 1998 ... mais ils sont là maintenant pour des raisons de "compatibilité".

---

Résumé

La STL est des conteneurs, des algorithmes et itérateurs.

Les chaînes et les flux ont été adoptés pour C++ 98, puis vers l'arrière -adopté pour le SGI STL moderne.

La question de savoir si les chaînes font partie ou non du "STL" dépend de la logique et de la raison, ou de l'appel de la bibliothèque standard "STL".

Espérons que cela aide.

Answer 2

Cela fait partie de STL en effet. Et std :: string est juste basic_string typedef. C'est un conteneur, spécialisé (pas en «spécialisation» en C++, ce qui signifie :)) pour le stockage de données avec une sémantique de chaîne. Aucune idée sur Stepanov si. Il convient de mentionner que STL est "Standard Template Library", et pas seulement la sous-partie du conteneur. Cela inclut les algorithmes, les flux et certains traits.

Answer 3

Il n'y a pas de vraie réponse à cela. D'une part, std::string a été développé entièrement indépendamment des autres conteneurs. D'un autre côté, il en a assez ajouté pour répondre à toutes les exigences d'un conteneur à accès aléatoire. Que vous choisissiez ou non de classer cela dans le cadre de "STL" dépend entièrement de vous - en fin de compte, cela ne fait que souligner le fait que "STL" n'a pas de définition unique convenue, et les chances de la voir soudainement gagner un sens clair est distant (pour le dire gentiment). IOW, "STL" est une abréviation moche à utiliser parce que les gens l'utilisent pour signifier au moins trois choses différentes - mais, malheureusement, il n'y a pas de meilleure abréviation avec une meilleure définition, donc STL reste en usage et va probablement continuer à le faire (et continuer à entraver la communication) indéfiniment.