Perché tutte le funzioni <algoritmo> accettano solo intervalli, non contenitori?

Ci sono molte funzioni utili in <algorithm>, ma tutte operano su "sequenze" - coppie di iteratori. Ad esempio, se ho un contenitore e mi piace eseguirlo std::accumulate, devo scrivere:

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

Quando tutto ciò che intendo fare è:

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

Che è un po 'più leggibile e più chiaro, ai miei occhi.

Ora posso vedere che potrebbero esserci casi in cui vorresti operare solo su parti di un contenitore, quindi è sicuramente utile avere l' opzione di passare intervalli. Ma almeno nella mia esperienza, è un caso speciale raro. Di solito vorrei operare su interi contenitori.

È facile scrivere una funzione wrapper che accetta un contenitore e chiama begin()e end()su di esso, ma tali funzioni di convenienza non sono incluse nella libreria standard.

Mi piacerebbe conoscere il ragionamento alla base di questa scelta di design STL.

... è sicuramente utile avere la possibilità di passare intervalli. Ma almeno nella mia esperienza, è un caso speciale raro. Di solito vorrei operare su interi contenitori

Potrebbe trattarsi di un raro caso speciale nella tua esperienza , ma in realtà l' intero contenitore è il caso speciale e l' intervallo arbitrario è il caso generale.

Hai già notato che puoi implementare l' intera custodia del contenitore utilizzando l'interfaccia corrente, ma non puoi fare il contrario.

Quindi, lo scrittore di biblioteche poteva scegliere tra l'implementazione di due interfacce in anticipo, o solo l'implementazione di una che copre ancora tutti i casi.

È facile scrivere una funzione wrapper che accetta un contenitore e chiama da inizio () e fine (), ma tali funzioni di convenienza non sono incluse nella libreria standard

Vero, soprattutto perché le funzioni gratuite std::begine std::endora sono incluse.

Quindi, supponiamo che la libreria fornisca il sovraccarico di convenienza:

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

ora deve anche fornire il sovraccarico equivalente prendendo un funzione di confronto e dobbiamo fornire gli equivalenti per ogni altro algoritmo.

Ma almeno abbiamo coperto tutti i casi in cui vogliamo operare su un contenitore pieno, giusto? Bene, non proprio. Tener conto di

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

Se vogliamo gestire il funzionamento all'indietro sui container, abbiamo bisogno di un altro metodo (o coppia di metodi) per algoritmo esistente.

Quindi, l'approccio basato sul range è più generale nel senso semplice che:

• può fare tutto ciò che può fare la versione dell'intero contenitore
• l'approccio dell'intero contenitore raddoppia o triplica il numero di sovraccarichi richiesti, pur essendo meno potente
• gli algoritmi basati su intervallo sono anche componibili (è possibile impilare o concatenare adattatori iteratori, sebbene ciò sia più comunemente fatto in linguaggi funzionali e Python)

C'è un'altra ragione valida, ovviamente, che è che era già molto lavoro per standardizzare la STL, e gonfiarla con involucri di comodo prima che fosse ampiamente usata non sarebbe un grande uso del tempo limitato del comitato. Se sei interessato, puoi trovare il rapporto tecnico di Stepanov & Lee qui

Come menzionato nei commenti, Boost.Range offre un approccio più recente senza richiedere modifiche allo standard.

Si scopre che c'è un articolo di Herb Sutter proprio su questo argomento. Fondamentalmente, il problema è l'ambiguità del sovraccarico. Dato quanto segue:

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

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

E aggiungendo quanto segue:

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

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

Renderà difficile distinguere 4e 1correttamente.

I concetti, come proposti ma alla fine non inclusi in C ++ 0x, avrebbero risolto questo problema ed è anche possibile aggirarlo usando enable_if. Per alcuni algoritmi, non è affatto un problema. Ma hanno deciso di non farlo.

Ora dopo aver letto tutti i commenti e le risposte qui, penso che gli rangeoggetti sarebbero la soluzione migliore. Penso che darò un'occhiata Boost.Range.

Fondamentalmente una decisione legacy. Il concetto di iteratore è modellato su puntatori, ma i contenitori non sono modellati su matrici. Inoltre, poiché le matrici sono difficili da passare (in genere è necessario un parametro di modello non di tipo per la lunghezza), abbastanza spesso una funzione ha solo puntatori disponibili.

Ma sì, col senno di poi la decisione è sbagliata. Saremmo stati meglio con un oggetto range costruibile da begin/endo begin/length; ora abbiamo invece più _nalgoritmi con suffisso.

Aggiungerli non otterresti alcun potere (puoi già fare l'intero contenitore chiamando .begin()e .end()te stesso) e aggiungerebbe un'altra cosa alla libreria che deve essere specificata correttamente, aggiunta alle librerie dai fornitori, testata, mantenuta, ecc, ecc.

In breve, probabilmente non è lì perché non vale la pena mantenere un set di template extra solo per salvare gli utenti dell'intero container dalla digitazione di un parametro di chiamata di funzione extra.

Ormai, http://en.wikipedia.org/wiki/C++11#Range-based_for_loop è una bella alternativa a std::for_each. Osservare, nessun iteratore esplicito:

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

(Ispirato da https://stackoverflow.com/a/694534/2097284 .)