Por que os intervalos do iterador padrão [começam, terminam) em vez de [começam, terminam]?

Por que o Padrão define end()como um passado após o final, em vez de no final real?

O melhor argumento é facilmente o do próprio Dijkstra :

• Você quer que o tamanho do intervalo para ser um simples diferença final  -  começar ;

• incluir o limite inferior é mais "natural" quando as seqüências degeneram para vazias e também porque a alternativa ( excluindo o limite inferior) exigiria a existência de um valor sentinela "um antes do início".

Você ainda precisa justificar por que começa a contar com zero, em vez de um, mas isso não fazia parte da sua pergunta.

A sabedoria por trás da convenção [começo, fim] compensa várias vezes quando você tem algum tipo de algoritmo que lida com várias chamadas aninhadas ou iteradas para construções baseadas em intervalo, que são encadeadas naturalmente. Por outro lado, o uso de um intervalo duplamente fechado resultaria em códigos isolados e extremamente desagradáveis ​​e barulhentos. Por exemplo, considere uma partição [ n ₀ , n ₁ ) [ n ₁ , n ₂ ) [ n ₂ , n ₃ ). Outro exemplo é o loop de iteração padrão for (it = begin; it != end; ++it), que executa os end - begintempos. O código correspondente seria muito menos legível se as duas extremidades fossem inclusivas - e imagine como você lidaria com intervalos vazios.

Finalmente, também podemos argumentar bem por que a contagem deve começar em zero: com a convenção semi-aberta para os intervalos que acabamos de estabelecer, se você receber um intervalo de N elementos (digamos, para enumerar os membros de uma matriz), então 0 é o "começo" natural, para que você possa escrever o intervalo como [0, N ), sem deslocamentos ou correções difíceis.

Em poucas palavras: o fato de não vermos o número 1em todos os lugares nos algoritmos baseados em intervalo é uma conseqüência direta e a motivação da convenção [início, fim].

Na verdade, muitas coisas relacionadas ao iterador de repente fazem muito mais sentido se você considerar que os iteradores não apontam para os elementos da sequência, mas no meio , com a desreferenciação acessando o próximo elemento à sua direita. Então, o iterador "one end end" faz repentinamente sentido imediato:

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

Obviamente beginaponta para o início da sequência e endaponta para o final da mesma sequência. A desreferenciação beginacessa o elemento A, e a desreferenciação endnão faz sentido porque não há nenhum elemento certo para ele. Além disso, adicionar um iterador ino meio fornece

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

e você vê imediatamente que o intervalo de elementos de begina icontém os elementos Ae Benquanto o intervalo de elementos de ia endcontém os elementos Ce D. A desreferenciação ifornece o elemento certo, que é o primeiro elemento da segunda sequência.

Mesmo o "off-by-one" para iteradores reversos repentinamente se torna óbvio assim: a reversão dessa sequência fornece:

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

Escrevi os iteradores não reversos (base) correspondentes entre parênteses abaixo. Você vê, o iterador reverso pertencente a i( ao qual eu nomeei ri) ainda aponta entre os elementos Be C. No entanto, devido à reversão da sequência, agora o elemento Bestá à direita.

Por que o Padrão define end()como um passado após o final, em vez de no final real?

Porque:

1. Evita manuseio especial para intervalos vazios. Para intervalos vazios, begin()é igual a end()&
2. Isso simplifica o critério final para loops que iteram sobre os elementos: os loops simplesmente continuam enquanto end()não forem atingidos.

Porque então

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

e você não terá que fazer coisas estranhas como

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

e você acidentalmente não escreverá códigos errados 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

Além disso: o que find()retornaria se end()apontado para um elemento válido?
Você realmente quer outro membro do chamado invalid()que retorna um iterador inválido ?!
Dois iteradores já são dolorosos o suficiente ...

Ah, e veja este post relacionado .

Além disso:

Se o endfoi antes do último elemento, como você estaria insert()no final verdadeiro ?!

O idioma do iterador de intervalos semi-fechados [begin(), end())é originalmente baseado na aritmética do ponteiro para matrizes simples. Nesse modo de operação, você teria funções que receberam uma matriz e um tamanho.

void func(int* array, size_t size)

A conversão para intervalos semi-fechados [begin, end)é muito simples quando você tem essa informação:

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

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

Para trabalhar com faixas totalmente fechadas, é mais difícil:

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

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

Como os ponteiros para matrizes são iteradores em C ++ (e a sintaxe foi projetada para permitir isso), é muito mais fácil chamar std::find(array, array + size, some_value)do que chamar std::find(array, array + size - 1, some_value).

Além disso, se você trabalha com faixas semi-fechadas, pode usar o !=operador para verificar a condição final, porque (se seus operadores estão definidos corretamente) <implica !=.

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

No entanto, não há uma maneira fácil de fazer isso com faixas totalmente fechadas. Você está preso <=.

O único tipo de iterador que suporta <e >opera em C ++ são iteradores de acesso aleatório. Se você tivesse que escrever um <=operador para cada classe de iterador em C ++, seria necessário tornar todos os seus iteradores totalmente comparáveis ​​e haveria menos opções para criar iteradores menos capazes (como os iteradores bidirecionais emstd::list ou os iteradores de entrada operam iostreams) se o C ++ usasse faixas totalmente fechadas.

Com o end()apontador no final, é fácil iterar uma coleção com um loop for:

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

Ao end()apontar para o último elemento, um loop seria mais complexo:

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

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

    it++;
}

1. Se um contêiner estiver vazio begin() == end(),.
2. Os programadores de C ++ tendem a usar em !=vez de <(menos que) em condições de loop, portanto, end()é conveniente apontar para uma posição inicial.