Pourquoi toutes les fonctions <algorithm> ne prennent-elles que des plages, pas des conteneurs?

Il y a beaucoup de fonctions utiles dans <algorithm>, mais toutes fonctionnent sur des "séquences" - des paires d'itérateurs. Par exemple, si j’ai un conteneur et que j’aime courir std::accumulatedessus, j’ai besoin d’écrire:

std::vector<int> myContainer = ...;
int sum = std::accumulate(myContainer.begin(), myContainer.end(), 0);

Quand tout ce que je compte faire, c'est:

int sum = std::accumulate(myContainer, 0);

Ce qui est un peu plus lisible et plus clair, à mes yeux.

Maintenant, je peux voir que dans certains cas, vous voudrez peut-être n’utiliser que des parties d’un conteneur. Il est donc certainement utile d’avoir la possibilité de passer des plages. Mais au moins d'après mon expérience, c'est un cas spécial rare. Je veux généralement opérer sur des conteneurs entiers.

Il est facile d'écrire une fonction d'enveloppe qui prend un récipient et des appels begin()et end()à ce sujet , mais ces fonctions pratiques ne sont pas inclus dans la bibliothèque standard.

J'aimerais connaître le raisonnement derrière ce choix de design STL.

... il est certainement utile d'avoir la possibilité de passer des plages. Mais au moins d'après mon expérience, c'est un cas spécial rare. Je veux généralement opérer sur des conteneurs entiers

Selon votre expérience , il s’agit peut-être d’un cas rare , mais en réalité, le conteneur dans son ensemble constitue le cas particulier et la plage arbitraire le cas général.

Vous avez déjà remarqué que vous pouvez implémenter l' intégralité du conteneur en utilisant l'interface actuelle, mais vous ne pouvez pas faire l'inverse.

Ainsi, le bibliothécaire-rédacteur avait le choix entre implémenter deux interfaces à l’avance ou n’en implémenter qu’une seule qui couvre toujours tous les cas.

Il est facile d'écrire une fonction wrapper qui prend un conteneur et appelle les commandes begin () et end (), mais ces fonctions ne sont pas incluses dans la bibliothèque standard.

C'est vrai, d'autant plus que les fonctions libres std::beginet std::endsont maintenant incluses.

Donc, disons que la bibliothèque fournit la surcharge de commodité:

template <typename Container>
void sort(Container &c) {
  sort(begin(c), end(c));
}

maintenant, il doit également fournir la surcharge équivalente en prenant un foncteur de comparaison, et nous devons fournir les équivalents pour tout autre algorithme.

Mais nous avons au moins couvert tous les cas où nous souhaitons opérer avec un conteneur complet, non? Pas tout à fait. Considérer

std::for_each(c.rbegin(), c.rend(), foo);

Si nous voulons gérer les opérations en arrière sur les conteneurs, nous avons besoin d' une autre méthode (ou d'une paire de méthodes) par algorithme existant.

L’approche basée sur la plage est donc plus générale dans le sens simple qui suit:

• il peut tout faire de la version contenant entier
• l'approche globale du conteneur double ou triple le nombre de surcharges requises, tout en restant moins puissante
• les algorithmes basés sur les plages sont également composables (vous pouvez empiler ou chaîner des adaptateurs d'itérateur, bien que cela se fasse plus couramment dans les langages fonctionnels et en Python)

Bien sûr, il existe une autre raison valable, à savoir que la standardisation du STL nécessitait déjà beaucoup de travail et que le gonfler avec des enveloppes de commodité avant qu'il ne soit largement utilisé ne serait pas une grande utilisation du temps limité des comités. Si vous êtes intéressé, vous trouverez le rapport technique de Stepanov & Lee ici

Comme mentionné dans les commentaires, Boost.Range fournit une approche plus récente sans nécessiter de modification de la norme.

Il s'avère qu'il y a un article de Herb Sutter sur ce sujet même. Fondamentalement, le problème est l’ambiguïté de surcharge. Compte tenu de ce qui suit:

template<typename Iter>
void sort( Iter, Iter ); // 1

template<typename Iter, typename Pred>
void sort( Iter, Iter, Pred ); // 2

Et en ajoutant ce qui suit:

template<typename Container>
void sort( Container& ); // 3

template<typename Container, typename Pred>
void sort( Container&, Pred ); // 4

Cela rendra difficile à distinguer 4et 1correctement.

Les concepts, tels que proposés mais finalement pas inclus dans C ++ 0x, auraient résolu ce problème, et il est également possible de les contourner à l'aide de enable_if. Pour certains algorithmes, cela ne pose aucun problème. Mais ils ont décidé de ne pas le faire.

Maintenant, après avoir lu tous les commentaires et réponses ici, je pense que les rangeobjets seraient la meilleure solution. Je pense que je vais regarder Boost.Range.

Fondamentalement, une décision héritée. Le concept d'itérateur est calqué sur les pointeurs, mais les conteneurs ne sont pas calqués sur des tableaux. De plus, comme les tableaux sont difficiles à transmettre (en général, il leur faut un paramètre de modèle non typé pour la longueur), très souvent, une fonction ne dispose que de pointeurs.

Mais oui, avec le recul, la décision est fausse. Nous aurions mieux fait d'utiliser un objet range pouvant être construit à partir de begin/endou begin/length; nous avons maintenant plusieurs _nalgorithmes suffixés.

Leur ajout ne vous apporterait aucun pouvoir (vous pouvez déjà traiter tout le conteneur en appelant vous .begin()- .end()même), et cela ajouterait une dernière chose à la bibliothèque qui doit être correctement spécifiée, ajoutée aux bibliothèques par les fournisseurs, testée, maintenue. etc.

En bref, ce n'est probablement pas là car il ne vaut pas la peine de conserver un ensemble de modèles supplémentaires simplement pour éviter aux utilisateurs de conteneur entier de saisir un paramètre d'appel de fonction supplémentaire.

A ce jour, http://en.wikipedia.org/wiki/C++11#Range-based_for_loop est une bonne alternative à std::for_each. Observez, pas d'itérateurs explicites:

int a[5] = {1, 2, 3, 4, 5};
for (auto &i: a) { i *= 2; }

(Inspiré par https://stackoverflow.com/a/694534/2097284 .)