Algoritmos STL tomando el contenedor completo en lugar de .begin(), end() como arg?

Question

Algoritmos STL independientes (como std::count_if) toman un par de iteradores. En todos los casos en los que uso (y en todos los ejemplos que he visto en línea!), Me encuentro escribiendo

std::count_if(myContainer.begin(),myContainer.end(), /* ... */); 

¿Hay una razón por la cual las plantillas de la taquigrafía del estilo

std::count_if(myContainer, /* ... */); 

no son siempre que, dado que más de que no es la operación realizada en todo el contenedor? ¿Simplemente lo pasé por alto? ¿La respuesta es diferente para C++ 11 y C++ 03?

Answer 1

hay un bonito blog-post por Herb Sutter discutir la cuestión . Lo esencial es que la adición de sobrecargas basadas en contenedores para algoritmos puede crear ambigüedades si ya existe una sobrecarga para ese algoritmo con el mismo número de parámetros de plantilla. Los conceptos estaban destinados a solucionar ese problema.

Answer 2

Simplemente porque los algoritmos STL están conectados/hablan con el contenedor mediante iteradores.

Answer 3

Una razón podría ser para proporcionar la flexibilidad para la gama de iteradores. Puede que no necesite para recorrer todos los elementos en algún momento:

<iterator> it = myContainer.begin(); 
it++; // do something 
it++; // do something 
... 
std::count_if(it, myContainer.end(), /* ... */); 

Además, siempre se puede tener una envoltura que lo hace por usted:

template<typename T> 
... count_if (T myContainer, ...) 
{ 
    std::count_if(myContainer.begin(), myContainer.end(), /* ... */); 
} 

Answer 4

El principio y la flexibilidad de STL se deben principalmente a que funcionan en iteradores en lugar de en contenedores. No es un gran problema, puede volver a utilizar el truco que estoy usando desde mis primeros años C:

#define FULL_RANGE(c) (c).begin(), (c).end() 

std::copy(FULL_RANGE(c), std::ostream_iterator<c::value_type>(cout, "\n"));