Dlaczego wszystkie funkcje <algorytmu> zajmują tylko zakresy, a nie kontenery?

Istnieje wiele przydatnych funkcji <algorithm>, ale wszystkie działają na „sekwencjach” - parach iteratorów. Na przykład, jeśli mam kontener i lubię na nim biegać std::accumulate, muszę napisać:

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

Gdy wszystko, co zamierzam zrobić, to:

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

Co jest w moich oczach nieco bardziej czytelne i wyraźniejsze.

Teraz widzę, że mogą zdarzyć się przypadki, w których chciałbyś operować tylko na częściach kontenera, więc zdecydowanie warto mieć opcję przekazywania zakresów. Ale przynajmniej z mojego doświadczenia to rzadki wyjątkowy przypadek. Zazwyczaj będę chciał operować na całych kontenerach.

Łatwo jest napisać funkcję otoki, który trwa do pojemnika i wywołuje begin()i end()na nim, ale takie funkcje convenience nie są zawarte w standardowej bibliotece.

Chciałbym poznać uzasadnienie tego wyboru projektu STL.

... zdecydowanie warto mieć opcję przekazywania zakresów. Ale przynajmniej z mojego doświadczenia to rzadki wyjątkowy przypadek. Zazwyczaj będę chciał operować na całych kontenerach

Może to być rzadki szczególny przypadek z twojego doświadczenia , ale w rzeczywistości cały pojemnik jest szczególnym przypadkiem, a arbitralny zasięg jest przypadkiem ogólnym.

Zauważyłeś już, że możesz zaimplementować całą skrzynkę kontenera za pomocą bieżącego interfejsu, ale nie możesz tego zrobić.

Tak więc autor biblioteki miał wybór między implementacją dwóch interfejsów z góry, a tylko implementacją jednego, który wciąż obejmuje wszystkie przypadki.

Łatwo jest napisać funkcję otoki, która zabiera kontener i wywołuje na nim wywołania begin () i end (), ale takie funkcje wygody nie są zawarte w standardowej bibliotece

To prawda, zwłaszcza, że ​​darmowe funkcje std::begini std::endsą teraz włączone.

Powiedzmy, że biblioteka zapewnia przeciążenie wygody:

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

teraz musi również zapewnić równoważne przeciążenie, biorąc funktor porównawczy, i musimy zapewnić odpowiedniki dla każdego innego algorytmu.

Ale przynajmniej objęliśmy każdą sprawę, w której chcemy operować na pełnym kontenerze, prawda? Cóż, niezupełnie. Rozważać

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

Jeśli chcemy poradzić sobie z operacjami wstecznymi na kontenerach, potrzebujemy innej metody (lub pary metod) dla każdego istniejącego algorytmu.

Tak więc podejście oparte na zakresie jest bardziej ogólne w prostym sensie, że:

• może zrobić wszystko, co może zrobić cała wersja kontenera
• podejście całego kontenera podwaja lub trzykrotnie liczbę wymaganych przeciążeń, a jednocześnie jest mniej mocne
• algorytmy oparte na zakresie są również możliwe do skomponowania (można układać w stosy lub łączyć łańcuchy iteratorów, chociaż jest to częściej wykonywane w językach funkcjonalnych i Pythonie)

Oczywiście istnieje jeszcze jeden ważny powód, który polegał na tym, że standaryzacja STL była już bardzo pracochłonna, a nadmuchiwanie go wygodnymi opakowaniami, zanim został on szeroko użyty, nie byłby świetnym wykorzystaniem ograniczonego czasu komitetu. Jeśli jesteś zainteresowany, możesz znaleźć raport techniczny Stepanova i Lee tutaj

Jak wspomniano w komentarzach, Boost.Range zapewnia nowsze podejście bez konieczności wprowadzania zmian w standardzie.

Okazuje się, że jest artykuł autorstwa Herb Sutter na ten właśnie temat. Zasadniczo problemem jest niejednoznaczność przeciążenia. Biorąc pod uwagę następujące kwestie:

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

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

I dodając następujące:

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

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

Utrudni to prawidłowe 4i 1prawidłowe rozróżnienie .

Pojęcia zaproponowane, ale ostatecznie nieuwzględnione w C ++ 0x, rozwiązałyby to, a także można je obejść za pomocą enable_if. W przypadku niektórych algorytmów nie stanowi to żadnego problemu. Ale zdecydowali się tego nie robić.

Teraz, po przeczytaniu wszystkich komentarzy i odpowiedzi tutaj, myślę, że rangeobiekty byłyby najlepszym rozwiązaniem. Myślę, że popatrzę Boost.Range.

Zasadniczo stara decyzja. Koncepcja iteratora jest wzorowana na wskaźnikach, ale pojemniki nie są modelowane na tablicach. Co więcej, ponieważ tablice są trudne do przekazania (ogólnie potrzeba nieparametrowego parametru szablonu), dość często funkcja ma dostępne tylko wskaźniki.

Ale tak, z perspektywy czasu decyzja jest zła. Lepiej byłoby nam, gdyby obiekt zasięgu można było zbudować z jednego begin/endlub drugiego begin/length; teraz _nzamiast tego mamy wiele sufiksowanych algorytmów.

Dodanie ich nie przyniesie ci żadnej mocy (możesz już zrobić cały kontener, dzwoniąc .begin()i .end()sam), i doda jeszcze jedną rzecz do biblioteki, która musi być odpowiednio określona, ​​dodana do bibliotek przez dostawców, przetestowana, utrzymana, itd itd.

Krótko mówiąc, prawdopodobnie nie ma go tam, ponieważ nie warto zadbać o utrzymanie zestawu dodatkowych szablonów, aby uratować użytkowników z całego kontenera przed wpisaniem jednego dodatkowego parametru wywołania funkcji.

Do tej pory http://en.wikipedia.org/wiki/C++11#Range-based_for_loop jest dobrą alternatywą dla std::for_each. Zauważ, że nie ma wyraźnych iteratorów:

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

(Zainspirowany https://stackoverflow.com/a/694534/2097284 .)