Qu'est-ce qui est si génial à STL ?

Question

Je suis un développeur Java qui essaie d'apprendre le C++. J'ai lu à plusieurs reprises sur Internet (y compris sur Stack Overflow) que STL est la meilleure bibliothèque de collections que l'on puisse trouver en Java. tout la langue. (Désolé, je n'ai pas de citations pour cela)

Cependant, après avoir étudié un peu de STL, je ne vois vraiment pas ce qui rend la STL si spéciale. Pourriez-vous m'éclairer sur ce qui différencie la STL des bibliothèques de collections d'autres langages et qui fait d'elle la meilleur bibliothèque de collection ?

Answer 1

Ce n'est pas tant qu'il soit "génial" ou "la meilleure bibliothèque de collections que vous pouvez obtenir dans *tout* langage", mais il a une philosophie différente de celle de nombreux autres langages.

En particulier, la bibliothèque standard C++ utilise une fonction programmation générique plutôt qu'un paradigme de orienté objet qui est commun à des langages comme Java et C#. C'est-à-dire que vous avez une définition " générique " de ce qu'est un iterator devrait être, et ensuite vous pouvez implémenter la fonction for_each o sort o max_element qui prend tout qui implémente la classe iterator sans avoir à hériter d'une interface de base "Iterator" ou autre.

Answer 2

Qu'est-ce qui est si bien dans la STL ?

La STL a la particularité d'avoir été conçue très tôt et d'avoir réussi à utiliser le paradigme de la programmation générique C++ de manière très efficace.

Il a séparé efficacement les structures de données : vector , map ... et les algorithmes pour les exploiter. copy , transform ... en profitant des modèles pour le faire.

Il découple proprement les préoccupations et fournit des conteneurs génériques avec des crochets de personnalisation ( Comparator y Allocator paramètres du modèle).

Le résultat est très élégant (principe DRY) et très efficace grâce aux optimisations du compilateur, de sorte que les algorithmes générés à la main pour un conteneur donné ont peu de chances de faire mieux.

Cela signifie également qu'il est facilement extensible : vous pouvez créer votre propre conteneur avec l'interface que vous souhaitez, tant qu'il expose des itérateurs conformes à la STL, vous pourrez utiliser les algorithmes de la STL avec lui !

Et grâce à l'utilisation de traits, vous pouvez même appliquer les algorithmes sur des tableaux C par le biais de simples pointeurs ! Vous parlez de rétrocompatibilité !

Cependant, il aurait pu (peut-être) être meilleur...

Qu'est-ce qui n'est pas si bien dans la STL ?

Cela m'énerve vraiment que l'on doive toujours utiliser les itérateurs, je supporterais vraiment de pouvoir écrire : std::foreach(myVector, [](int x) { return x+1;}); parce qu'il faut bien l'admettre, la plupart du temps, on veut itérer sur l'ensemble du conteneur...

Mais ce qui est pire, c'est qu'à cause de ça :

set<int> mySet = /**/;

set<int>::const_iterator it = std::find(mySet.begin(), mySet.end(), 1005); // [1]
set<int>::const_iterator it = mySet.find(1005); // [2]

[1] y [2] sont effectuées de manière totalement différente, ce qui donne [1] ayant une complexité O(n) alors que [2] a une complexité O(log n) ! Ici, le problème est que les itérateurs font trop d'abstraction.

Je ne veux pas dire que les itérateurs n'ont pas de valeur, je veux simplement dire que fournir une interface exclusivement en termes d'itérateurs était un mauvais choix.

Je préfère de loin l'idée de vues sur les conteneurs, par exemple, regardez ce qui a été fait avec Boost.MPL . Avec une vue, vous manipulez votre conteneur avec une couche (paresseuse) de transformation. Cela donne des structures très efficaces qui vous permettent de filtrer certains éléments, d'en transformer d'autres etc...

Combinaison de vues y vérification des concepts Je pense que ces idées produiraient une bien meilleure interface pour les algorithmes STL (et résoudraient le problème de l'utilisation de ces algorithmes). find , lower_bound , upper_bound , equal_range ).

Cela permettrait également d'éviter les erreurs courantes d'utilisation de plages d'itérateurs mal définies et le comportement indéfini qui en résulte...

Answer 3

Ce que j'aime dans le STL, c'est sa robustesse. Il est facile de l'étendre. Certains se plaignent qu'elle est petite, qu'il lui manque de nombreux algorithmes ou itérateurs courants. Mais c'est précisément lorsque vous voyez à quel point il est facile d'ajouter les composants manquants dont vous avez besoin. En plus de cela, "small is beautiful" : vous avez environ 60 algorithmes, une poignée de conteneurs et une poignée d'itérateurs, mais la fonctionnalité est de l'ordre du produit de ceux-ci. Les interfaces des conteneurs restent petites et simples.

Parce qu'il est de bon ton d'écrire de petits algorithmes simples et modulaires, il devient plus facile de repérer les bogues et les trous dans vos composants. En même temps, aussi simples que soient les algorithmes et les itérateurs, ils sont extraordinairement robustes : vos algorithmes fonctionneront avec de nombreux itérateurs existants et à écrire, et vos itérateurs fonctionneront avec de nombreux algorithmes existants et à écrire.

J'aime aussi la simplicité du STL. Vous avez des conteneurs, vous avez des itérateurs et vous avez des algorithmes. C'est tout (je mens ici, mais c'est ce qu'il faut pour être à l'aise avec la bibliothèque). Vous pouvez mélanger différents algorithmes avec différents itérateurs et différents conteneurs. Il est vrai que certains d'entre eux ont des contraintes qui leur interdisent de travailler avec d'autres, mais en général, il y a beaucoup de possibilités de jouer avec.

Niklaus Wirth a dit qu'un programme est constitué d'algorithmes et de structures de données. C'est exactement ce qu'est la STL. Si Ruby et Python sont des super-héros des chaînes de caractères, alors C++ et la STL sont des super-héros des algorithmes et des conteneurs.

Answer 4

Les conteneurs de la STL sont agréables, mais ils ne sont pas très différents de ceux que vous trouverez dans d'autres langages de programmation. Ce qui rend les conteneurs de la STL utiles, c'est qu'ils s'intègrent parfaitement aux algorithmes. La flexibilité offerte par les algorithmes standard est inégalée dans les autres langages de programmation.

Sans les algorithmes, les conteneurs ne sont que cela. Des conteneurs. Rien de spécial en particulier.

Maintenant, si vous parlez de bibliothèques de conteneurs pour le C++ uniquement, il est peu probable que vous trouviez des bibliothèques aussi bien utilisées et testées que celles fournies par STL, ne serait-ce que parce qu'elles sont standard.

Answer 5

La STL fonctionne parfaitement avec les types intégrés. A std::array<int, 5> est exactement ça un tableau de 5 int s, ce qui consomme 20 octets sur une plate-forme 32 bits.

java.util.Arrays.asList(1, 2, 3, 4, 5) d'autre part, renvoie une référence à un objet contenant une référence à un tableau contenant des références à des objets Integer contenant int s. Oui, c'est 3 niveaux d'indirection, et je n'ose pas prédire combien d'octets cela consomme ;)