¿Por qué los rangos de iterador estándar [comenzar, finalizar] en lugar de [comenzar, finalizar]?

¿Por qué define el estándar? end() como uno pasado el final, en lugar de en el final real?

El mejor argumento fácilmente es el que hizo el propio Dijkstra :

• Desea que el tamaño del rango sea un simple final de diferencia  :  comience ;

• incluir el límite inferior es más "natural" cuando las secuencias degeneran en vacías, y también porque la alternativa ( excluyendo el límite inferior) requeriría la existencia de un valor centinela "uno antes del comienzo".

Todavía necesita justificar por qué comienza a contar en cero en lugar de uno, pero eso no era parte de su pregunta.

La sabiduría detrás de la convención [comenzar, finalizar] vale la pena una y otra vez cuando tiene algún tipo de algoritmo que trata con múltiples llamadas anidadas o iteradas a construcciones basadas en rangos, que se encadenan naturalmente. Por el contrario, el uso de un rango doblemente cerrado incurriría en códigos extraños y extremadamente desagradables y ruidosos. Por ejemplo, considere una partición [ n ₀ , n ₁ ) [ n ₁ , n ₂ ) [ n ₂ , n ₃ ). Otro ejemplo es el ciclo de iteración estándar for (it = begin; it != end; ++it), que se ejecutaend - begin tiempos. El código correspondiente sería mucho menos legible si ambos extremos fueran inclusivos, e imagine cómo manejaría los rangos vacíos.

Finalmente, también podemos hacer un buen argumento de por qué el conteo debe comenzar en cero: con la convención medio abierta para rangos que acabamos de establecer, si se le da un rango de N elementos (por ejemplo, enumerar los miembros de una matriz), entonces 0 es el "comienzo" natural para que pueda escribir el rango como [0, N ), sin correcciones ni compensaciones incómodas.

En pocas palabras: el hecho de que no veamos el número 1en todas partes en los algoritmos basados ​​en rango es una consecuencia directa de la convención [comienzo, fin] y motivación.

En realidad, muchas cosas relacionadas con iteradores de repente tienen mucho más sentido si consideras que los iteradores no apuntan a los elementos de la secuencia, sino en el medio , con la eliminación de la referencia para acceder al siguiente elemento directamente. Entonces el iterador de "un extremo pasado" de repente tiene sentido inmediato:

   +---+---+---+---+
   | A | B | C | D |
   +---+---+---+---+
   ^               ^
   |               |
 begin            end

Obviamente beginapunta al comienzo de la secuencia y endapunta al final de la misma secuencia. La desreferenciación beginaccede al elemento A, y la desreferenciación endno tiene sentido porque no tiene ningún elemento correcto. Además, agregar un iterador ien el medio da

   +---+---+---+---+
   | A | B | C | D |
   +---+---+---+---+
   ^       ^       ^
   |       |       |
 begin     i      end

e inmediatamente ve que el rango de elementos de begina icontiene los elementos Ay Bmientras que el rango de elementos de ia endcontiene los elementos Cy D. Desreferenciari le da al elemento el derecho, es el primer elemento de la segunda secuencia.

Incluso el "off-by-one" para iteradores inversos de repente se vuelve obvio de esa manera: invertir esa secuencia da:

   +---+---+---+---+
   | D | C | B | A |
   +---+---+---+---+
   ^       ^       ^
   |       |       |
rbegin     ri     rend
 (end)    (i)   (begin)

He escrito los correspondientes iteradores no inversos (base) entre paréntesis a continuación. Verá, el iterador inverso que pertenece a i(que he nombrado ri) todavía apunta entre elementos By C. Sin embargo, debido a la inversión de la secuencia, ahora el elemento Bestá a la derecha.

¿Por qué el Estándar defineend() como uno pasado el final, en lugar de en el final real?

Porque:

1. Evita manipulaciones especiales para rangos vacíos. Para rangos vacíos, begin()es igual a end()&
2. Simplifica el criterio de finalización para los bucles que iteran sobre los elementos: los bucles simplemente continúan mientras end()no se alcanza.

Porque entonces

size() == end() - begin()   // For iterators for whom subtraction is valid

y no tendrás que hacer cosas incómodas como

// Never mind that this is INVALID for input iterators...
bool empty() { return begin() == end() + 1; }

y no escribirás accidentalmente código erróneo como

bool empty() { return begin() == end() - 1; }    // a typo from the first version
                                                 // of this post
                                                 // (see, it really is confusing)

bool empty() { return end() - begin() == -1; }   // Signed/unsigned mismatch
// Plus the fact that subtracting is also invalid for many iterators

Además: ¿Qué find()devolvería si end()apuntara a un elemento válido?
¿ Realmente quieres que se llame a otro miembro invalid()que devuelva un iterador no válido?
Dos iteradores ya son lo suficientemente dolorosos ...

Ah, y mira esta publicación relacionada .

También:

Si el end fue antes del último elemento, ¿cómo llegarías insert()al verdadero final?

El idioma de iterador de rangos semicerrados [begin(), end())se basa originalmente en la aritmética de puntero para matrices simples. En ese modo de operación, tendría funciones a las que se les pasó una matriz y un tamaño.

void func(int* array, size_t size)

La conversión a rangos semicerrados [begin, end)es muy simple cuando tiene esa información:

int* begin;
int* end = array + size;

for (int* it = begin; it < end; ++it) { ... }

Para trabajar con rangos completamente cerrados, es más difícil:

int* begin;
int* end = array + size - 1;

for (int* it = begin; it <= end; ++it) { ... }

Dado que los punteros a las matrices son iteradores en C ++ (y la sintaxis fue diseñada para permitir esto), es mucho más fácil llamar std::find(array, array + size, some_value)que llamar std::find(array, array + size - 1, some_value).

Además, si trabaja con rangos semicerrados, puede usar el !=operador para verificar la condición final, porque (si sus operadores están definidos correctamente) <implica !=.

for (int* it = begin; it != end; ++ it) { ... }

Sin embargo, no hay una manera fácil de hacer esto con rangos completamente cerrados. Estás atrapado con <=.

El único tipo de iterador que admite <y >opera en C ++ son los iteradores de acceso aleatorio. Si tuviera que escribir un <=operador para cada clase de iterador en C ++, tendría que hacer que todos sus iteradores fueran totalmente comparables, y tendría menos opciones para crear iteradores menos capaces (como los iteradores bidireccionales activados std::listo los iteradores de entrada) que funcionan iostreams) si C ++ usa rangos completamente cerrados.

Con el end()señalador más allá del final, es fácil iterar una colección con un bucle for:

for (iterator it = collection.begin(); it != collection.end(); it++)
{
    DoStuff(*it);
}

Al end()señalar el último elemento, un bucle sería más complejo:

iterator it = collection.begin();
while (!collection.empty())
{
    DoStuff(*it);

    if (it == collection.end())
        break;

    it++;
}

1. Si un recipiente está vacío, begin() == end().
2. Los programadores de C ++ tienden a usar en !=lugar de <(menos de) en condiciones de bucle, por lo tanto, end()es conveniente apuntar a una posición fuera del extremo.