Perché non esiste una funzione membro for_each per ogni tipo di raccolta in stl?

Question

Per esempio:

v.for_each([](int i) { printf("%d\n", i); }); 

se molto più elegante e leggibile rispetto al comunemente usato:

std::for_each(v.begin(), v.end(), [](int i) { printf("%d\n", i); }); 

C'è un legittimo motivo di tale funzione membro non è presente nella norma?

Answer 1

Questo è il motivo di progettazione standard per l'intera libreria: contenitori separati dagli algoritmi.

Se lo facevi a modo tuo, dovresti implementare ogni funzione X per ogni contenitore Y, portandoti a implementazioni M * N se disponi di funzioni M e N contenitori.

Utilizzando gli iteratori e gli algoritmi di elaborazione funzionano su iteratori anziché su contenitori, è necessario implementare solo algoritmi M più interfacce iteratore.

Questa separazione significa anche che hai infinitamente più ampio campo di applicazione: gli algoritmi non possono semplicemente essere utilizzati per ogni contenitore libreria, ma per qualsiasi contenitore, presente o futuro, che qualcuno decide di scrivere e attrezzare con iteratori . Il riutilizzo finito e infinito è un argomento abbastanza forte! E chiamare gli algoritmi attraverso l'interfaccia generica e gratuita non aggiunge alcun costo.

Answer 2

Il semplice fatto è che il design della libreria standard deriva da un momento in cui il linguaggio non offriva molte funzionalità e molti progetti comuni, come i mixin basati su CRTP, non erano disponibili. Ciò significa che i design superiori che sono ovvi ora semplicemente non erano implementabili o progettabili quando è stata creata la libreria Standard.

Gli iteratori sono un'ottima implementazione generica, ma creano un'interfaccia generica. Trovo rattristante che invece di risolvere il problema con il design della libreria e di revisionarlo, invece hanno introdotto una funzione di caso speciale per un piccolo sottoinsieme del problema.

Answer 3

template <class InputIterator, class UnaryFunction> 
UnaryFunction for_each(InputIterator first, InputIterator last, UnaryFunction f); 

Come si può vedere for_each prende Iterator ingresso come parametro, in modo che qualsiasi contenitore STL che può fornire un iteratore di input compatibile (cioè a parte iteratore di ingresso, potrebbe anche essere bidirezionale, ad accesso casuale iteratore etc) sarebbe compatibile con std :: for_each. Progettando in questo modo, stl algoritmo separato generico dal tipo di dati (contenitori) che è più elegante generico &.

Answer 4

Perché lo richiederebbe?

Le funzioni membro servono solo se l'implementazione può essere resa più efficiente (set :: find è più efficiente di std :: find() su un set).

PS Oh, e se si vuole evitare onnipresente .begin(), en .end() chiamate, utilizzare Boost Range Algorithms. Dolce zucchero sintattico

comunque A Gamma Boost campione ispirato:

#include <boost/range/adaptors.hpp> 
#include <boost/range/algorithm.hpp> 
#include <boost/pending/integer_range.hpp> 

using namespace boost::adaptors; 

static int mod7(int v) 
    { return v % 7; } 

int main() 
{ 
    std::vector<int> v; 

    boost::copy(
      boost::make_integer_range(1,100) | transformed(mod7), 
      std::back_inserter(v)); 

    boost::sort(v); 

    boost::copy(
      v | reversed | uniqued, 
      std::ostream_iterator<int>(std::cout, ", ")); 
}