¿Por qué no hay una función para cada miembro para cada tipo de colección en stl?

Question

Por ejemplo:

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

si mucho más elegante y fácil de leer que el comúnmente utilizado:

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

¿Existe una razón legítima tal función miembro no se encuentra en la norma?

Answer 1

Esta es la lógica de diseño estándar para toda la biblioteca: Separa los contenedores de los algoritmos.

Si lo hiciste a tu manera, tendrías que implementar cada característica X para cada contenedor Y, lo que te llevaría a las implementaciones M * N si tienes M características y N contenedores.

Al utilizar iteradores y hacer que los algoritmos funcionen en iteradores en lugar de contenedores, solo tiene que implementar algoritmos M más N interfaces de iterador.

Esta separación también significa que tiene alcance infinitamente más amplio de aplicación: los algoritmos no sólo pueden ser utilizados para cada contenedor biblioteca, pero para cualquier contenedor, presente o futuro, que cualquier persona decide escribir y equipar con iteradores . La reutilización finita vs infinita es un argumento bastante fuerte. Y llamar a los algoritmos a través de la interfaz genérica gratuita no agrega ningún costo.

Answer 2

El hecho simple es que el diseño de la biblioteca estándar es de una época en la que el lenguaje no ofrecía muchas características, y muchos diseños comunes ahora, como las mixins basadas en CRTP, no existían. Esto significa que los diseños superiores que ahora son obvios simplemente no se podían implementar o designar cuando se creó la biblioteca estándar.

Los iteradores son una gran implementación genérica, pero hacen una interfaz genérica sucky. Me entristece que, en lugar de resolver el problema con el diseño de la biblioteca y revisarlo, introdujeran una función de lenguaje de caso especial para un pequeño subconjunto del problema.

Answer 3

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

Como se puede ver for_each toma iterador de entrada como en el parámetro, por lo que cualquier contenedor STL que puede proporcionar un iterador de entrada compatible (es decir, aparte de iterador de entrada, sino que también podría ser el acceso bidireccional, al azar iterador etc) sería compatible con std :: for_each. Al diseñar de esta manera, stl algoritmo genérico separado del tipo de datos (contenedores) que es más elegante & genérico.

Answer 4

¿Por qué lo necesitarías?

Las funciones de miembro solo sirven al propósito si la implementación se puede hacer más eficiente (set :: find es más eficiente que std :: find() en un conjunto).

PS Ah, y si se quiere evitar ubicua .begin(), en .end() llamadas, utilizar Boost Range Algorithms. dulce de azúcar sintáctica

Una gama aleatoria Boost muestra inspirada:

#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, ", ")); 
}