Por que todas as funções <algorithm> usam apenas intervalos, não contêineres?

Existem muitas funções úteis <algorithm>, mas todas elas operam em "sequências" - pares de iteradores. Por exemplo, se eu tenho um container e gostaria de rodar std::accumulatenele, preciso escrever:

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

Quando tudo que pretendo fazer é:

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

O que é um pouco mais legível e mais claro aos meus olhos.

Agora eu vejo que pode haver casos em que você deseja operar apenas em partes de um contêiner, por isso é definitivamente útil ter a opção de passar por intervalos. Mas pelo menos na minha experiência, esse é um caso especial raro. Normalmente, eu quero operar em contêineres inteiros.

É fácil escrever uma função wrapper que leva um recipiente e chamadas begin()e end()sobre ele, mas tais funções de conveniência não estão incluídos na biblioteca padrão.

Gostaria de saber o raciocínio por trás dessa opção de design da STL.

... é definitivamente útil ter a opção de passar intervalos. Mas pelo menos na minha experiência, esse é um caso especial raro. Normalmente, eu quero operar em contêineres inteiros

Pode ser um caso especial raro em sua experiência , mas, na realidade, todo o contêiner é o caso especial e o intervalo arbitrário é o caso geral.

Você já percebeu que é possível implementar todo o caso do contêiner usando a interface atual, mas não pode fazer o inverso.

Portanto, o escritor da biblioteca teve a opção de implementar duas interfaces antecipadamente ou apenas uma que ainda abrange todos os casos.

É fácil escrever uma função de invólucro que pega um contêiner e chama begin () e end () nele, mas essas funções de conveniência não estão incluídas na biblioteca padrão

Verdade, especialmente desde as funções gratuitas std::begine std::endagora estão incluídas.

Então, digamos que a biblioteca ofereça a sobrecarga de conveniência:

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

agora ele também precisa fornecer a sobrecarga equivalente usando um functor de comparação, e precisamos fornecer os equivalentes para todos os outros algoritmos.

Mas pelo menos cobrimos todos os casos em que queremos operar em um contêiner cheio, certo? Bem, não exatamente. Considerar

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

Se queremos lidar com a operação reversa em contêineres, precisamos de outro método (ou par de métodos) por algoritmo existente.

Portanto, a abordagem baseada em faixa é mais geral no sentido simples de que:

• ele pode fazer tudo o que a versão do contêiner inteiro pode
• a abordagem de todo o contêiner duplica ou triplica o número de sobrecargas necessárias, enquanto ainda é menos poderosa
• os algoritmos baseados em intervalo também são compostos (você pode empilhar ou encadear adaptadores de iteradores, embora isso seja mais comumente feito em linguagens funcionais e Python)

Há outro motivo válido, é claro, que já era muito trabalhoso padronizar o STL e inflá-lo com invólucros de conveniência antes que ele fosse amplamente utilizado não seria um ótimo uso do tempo limitado do comitê. Se você estiver interessado, pode encontrar o relatório técnico de Stepanov & Lee aqui

Conforme mencionado nos comentários, o Boost.Range fornece uma abordagem mais nova sem exigir alterações no padrão.

Acontece que há um artigo de Herb Sutter sobre esse assunto. Basicamente, o problema é a ambiguidade da sobrecarga. Dado o seguinte:

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

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

E adicionando o seguinte:

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

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

Tornará difícil distinguir 4e 1adequadamente.

Os conceitos, conforme propostos, mas não incluídos no C ++ 0x, teriam resolvido isso e também é possível contorná-lo usando enable_if. Para alguns dos algoritmos, não há problema algum. Mas eles decidiram contra.

Agora, depois de ler todos os comentários e respostas aqui, acho que os rangeobjetos seriam a melhor solução. Acho que vou dar uma olhada Boost.Range.

Basicamente, uma decisão herdada. O conceito de iterador é modelado em ponteiros, mas os contêineres não são modelados em matrizes. Além disso, como as matrizes são difíceis de passar (precisam de um parâmetro de modelo não-tipo para comprimento, em geral), muitas vezes uma função tem apenas ponteiros disponíveis.

Mas sim, em retrospectiva, a decisão está errada. Teríamos ficado melhor com um objeto de intervalo construtível a partir de begin/endou begin/length; agora temos vários _nalgoritmos com sufixo.

Adicionando-se você ganhar nenhum poder (você já pode fazer todo o recipiente chamando .begin()e .end()você mesmo), e gostaria de acrescentar mais uma coisa para a biblioteca que tem de ser devidamente especificado, adicionadas às bibliotecas pelos vendedores, testado, mantido, etc etc.

Em suma, provavelmente não está lá porque não vale a pena manter um conjunto de modelos extras apenas para evitar que usuários de contêineres inteiros digitem um parâmetro de chamada de função extra.

Até agora, http://en.wikipedia.org/wiki/C++11#Range-based_for_loop é uma boa alternativa para std::for_each. Observe, nenhum iterador explícito:

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

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