¿Por qué son los rangos de iteradores estándar [begin, end) en lugar de [begin, end]?

¿Por qué el Estándar define end() como uno más allá del final, en lugar del final real?

Porque:

1. Evita el manejo especial para rangos vacíos. Para rangos vacíos, begin() es igual a end() &
2. Hace que el criterio final sea simple para bucles que iteran sobre los elementos: Los bucles simplemente continúe mientras no se alcance end().

En realidad, muchas cosas relacionadas con los iteradores de repente tienen mucho más sentido si consideramos que los iteradores no apuntan a los elementos de la secuencia, sino entre, con desreferenciación accediendo al siguiente elemento directamente a él. Entonces el iterador" one past end " de repente tiene sentido inmediato:

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

Obviamente begin apunta al principio de la secuencia, y end apunta al final de la misma secuencia. La desreferenciación begin accede al elemento A, y desreferenciar end no tiene sentido porque no hay ningún elemento derecho a ello. Además, agregar un iterador i en el medio da

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

Y de inmediato ver que la gama de elementos de begin a i contiene los elementos de A y B, mientras que la variedad de elementos de i a end contiene los elementos de C y D. Dereferencing i da el derecho del elemento de él, que es el primer elemento de la segunda secuencia.

Incluso el "off-by-one" para reverse los iteradores de repente se vuelven obvios 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. Ves, el iterador inverso que pertenece a i (que he nombrado ri) todavía puntos entre los elementos B y C. Sin embargo, debido a la inversión de la secuencia, ahora element B está a la derecha de ella.

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

También: ¿Qué devolvería find() si end() apuntara a un elemento válido?
¿Realmente quieres otro miembro llamado invalid() que devuelva un iterador no válido?!
Dos iteradores ya es bastante doloroso...

Oh, y ver esto post relacionado .

También:

Si el end estaba antes del último elemento, ¿cómo insert() ¿en el verdadero final?!

El modismo iterador de rangos semi-cerrados [begin(), end()) se basa originalmente en la aritmética de punteros para matrices simples. En ese modo de operación, tendría funciones que se pasaron una matriz y un tamaño.

void func(int* array, size_t size)

Convertir a rangos medio cerrados [begin, end) es muy simple cuando tienes 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 matrices son iteradores en C++ (y la sintaxis fue diseñada para permitir esto), es mucho es más fácil llamar a std::find(array, array + size, some_value) que llamar a std::find(array, array + size - 1, some_value).

Además, si trabaja con rangos medio cerrados, 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 atascado con <=.

El único tipo de iterador que soporta operaciones < y > en C++ son los iteradores de acceso aleatorio. Si tuvieras que escribir una <= operador para cada clase de iterador en C++, tendría que hacer que todos sus iteradores sean completamente comparables, y tendría menos opciones para crear iteradores menos capaces (como los iteradores bidireccionales en std::list, o los iteradores de entrada que operan en iostreams) si C++ utiliza rangos completamente cerrados.

Con el end() apuntando al final, es fácil iterar una colección con un bucle for:

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

Con end() apuntando al ú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 contenedor está vacío, begin() == end().
2. Los programadores de C++ tienden a usar != en lugar de < (menos que) en condiciones de bucle, por lo tanto tener end() apuntando a una posición fuera del extremo es conveniente.