¿Por qué todas las funciones <algorithm> toman solo rangos, no contenedores?

Hay muchas funciones útiles <algorithm>, pero todas operan en "secuencias": pares de iteradores. Por ejemplo, si tengo un contenedor y me gusta ejecutarlo std::accumulate, necesito escribir:

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

Cuando todo lo que pretendo hacer es:

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

Lo cual es un poco más legible y más claro, a mis ojos.

Ahora puedo ver que puede haber casos en los que solo desee operar en partes de un contenedor, por lo que definitivamente es útil tener la opción de pasar rangos. Pero al menos en mi experiencia, ese es un caso especial raro. Por lo general, querré operar en contenedores enteros.

Es fácil escribir una función de contenedor que tiene un recipiente y las llamadas begin()y end()en él, pero este tipo de funciones de confort no están incluidos en la librería estándar.

Me gustaría saber el razonamiento detrás de esta elección de diseño STL.

... definitivamente es útil tener la opción de pasar rangos. Pero al menos en mi experiencia, ese es un caso especial raro. Por lo general, querré operar en contenedores completos

Puede ser un caso especial raro en su experiencia , pero en realidad todo el contenedor es el caso especial, y el rango arbitrario es el caso general.

Ya ha notado que puede implementar todo el caso del contenedor utilizando la interfaz actual, pero no puede hacer lo contrario.

Entonces, el escritor de la biblioteca tenía la opción de implementar dos interfaces por adelantado, o solo implementar una que todavía cubra todos los casos.

Es fácil escribir una función de contenedor que tome un contenedor y llame a begin () y end (), pero esas funciones de conveniencia no están incluidas en la biblioteca estándar

Es cierto, especialmente porque las funciones gratuitas std::beginy std::endahora están incluidas.

Entonces, digamos que la biblioteca proporciona la sobrecarga de conveniencia:

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

ahora también debe proporcionar la sobrecarga equivalente tomando un functor de comparación, y necesitamos proporcionar los equivalentes para cualquier otro algoritmo.

Pero al menos cubrimos todos los casos en los que queremos operar en un contenedor lleno, ¿verdad? Bueno, no del todo. Considerar

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

Si queremos manejar el funcionamiento al revés en contenedores, necesitamos otro método (o un par de métodos) por algoritmo existente.

Entonces, el enfoque basado en el rango es más general en el sentido simple de que:

• puede hacer todo lo que puede hacer la versión de contenedor completo
• el enfoque de contenedor completo duplica o triplica el número de sobrecargas requeridas, sin dejar de ser menos potente
• los algoritmos basados ​​en rango también son componibles (puede apilar o encadenar adaptadores iteradores, aunque esto se hace más comúnmente en lenguajes funcionales y Python)

Hay otra razón válida, por supuesto, que es que era ya un montón de trabajo para obtener el STL normalizado, e inflando con envolturas de conveniencia antes de que había sido ampliamente utilizado no sería un gran uso del tiempo comité limitado. Si está interesado, puede encontrar el informe técnico de Stepanov & Lee aquí.

Como se mencionó en los comentarios, Boost.Range proporciona un enfoque más nuevo sin requerir cambios en el estándar.

Resulta que hay un artículo de Herb Sutter sobre este mismo tema. Básicamente, el problema es la sobrecarga de la ambigüedad. Dado lo siguiente:

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

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

Y agregando lo siguiente:

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

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

Hará difícil distinguir 4y 1correctamente.

Los conceptos, tal como se propusieron pero finalmente no se incluyen en C ++ 0x, lo habrían resuelto, y también es posible eludirlo usando enable_if. Para algunos de los algoritmos, no hay ningún problema. Pero decidieron no hacerlo.

Ahora, después de leer todos los comentarios y respuestas aquí, creo que los rangeobjetos serían la mejor solución. Creo que voy a echar un vistazo Boost.Range.

Básicamente una decisión heredada. El concepto de iterador se modela en punteros, pero los contenedores no se modelan en matrices. Además, dado que las matrices son difíciles de pasar (en general necesitan un parámetro de plantilla que no sea de tipo para la longitud), a menudo una función solo tiene punteros disponibles.

Pero sí, en retrospectiva, la decisión es incorrecta. Hubiéramos estado mejor con un objeto de rango construible a partir de begin/endo begin/length; ahora tenemos múltiples _nalgoritmos con sufijo en su lugar.

Agregarlos no le otorgaría poder (ya puede hacer todo el contenedor llamando .begin()y .end()usted mismo), y agregaría una cosa más a la biblioteca que debe ser especificada correctamente, agregada a las bibliotecas por los proveedores, probada, mantenida, etcétera etcétera.

En resumen, probablemente no esté allí porque no vale la pena mantener un conjunto de plantillas adicionales solo para evitar que los usuarios de contenedores completos escriban un parámetro de llamada de función adicional.

Por ahora, http://en.wikipedia.org/wiki/C++11#Range-based_for_loop es una buena alternativa a std::for_each. Observe, no hay iteradores explícitos:

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

(Inspirado en https://stackoverflow.com/a/694534/2097284 .)