Чому всі функції <алгоритму> приймають лише діапазони, а не контейнери?

У програмах є багато корисних функцій <algorithm>, але всі вони працюють на «послідовностях» - парах ітераторів. Наприклад, якщо я маю контейнер і люблю бігати std::accumulateпо ньому, мені потрібно написати:

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

Коли все, що я маю намір зробити:

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

Що в моїх очах трохи читабельніше і зрозуміліше.

Тепер я бачу, що можуть бути випадки, коли ви хочете оперувати лише частинами контейнера, тому, безумовно, корисно мати можливість проходження діапазонів. Але, принаймні, з мого досвіду, це рідкісний особливий випадок. Зазвичай я хочу оперувати цілими контейнерами.

Написати функцію обгортки, яка приймає контейнер, дзвонить begin()і end()на нього легко, але такі зручні функції не включені до стандартної бібліотеки.

Мені хотілося б дізнатися обґрунтування цього вибору дизайну STL.

... напевно корисно мати можливість проходження діапазонів. Але, принаймні, з мого досвіду, це рідкісний особливий випадок. Зазвичай я хочу оперувати цілими контейнерами

Це може бути рідкісним особливим випадком у вашому досвіді , але насправді весь контейнер - це особливий випадок, а довільний діапазон - загальний випадок.

Ви вже помітили, що ви можете реалізувати весь корпус контейнера за допомогою поточного інтерфейсу, але не можете зробити зворотне.

Отже, у бібліотечного письменника був вибір між реалізацією двох інтерфейсів на передній частині, або лише тим, хто реалізує, який все ще охоплює всі випадки.

Легко написати функцію обгортки, яка бере контейнер і викликає на ньому запуск () і закінчення (), але такі зручні функції не включені до стандартної бібліотеки

Правда, тим більше, що безкоштовні функції std::beginі std::endзараз включені.

Скажімо, бібліотека забезпечує зручне перевантаження:

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

тепер він також повинен забезпечити еквівалентну перевантаження, приймаючи функцію порівняння, і нам потрібно надати еквіваленти для кожного іншого алгоритму.

Але ми принаймні висвітлювали кожен випадок, коли ми хочемо працювати на повному контейнері, правда? Ну, не зовсім. Розглянемо

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

Якщо ми хочемо , щоб впоратися з операційними назад на контейнерах, нам потрібна інший метод (або пару методів) в відповідно з існуючим алгоритмом.

Отже, підхід на основі дальності є більш загальним у простому розумінні, що:

• він може зробити все, що може використовувати версія для контейнерів
• підхід із цілим контейнером подвоює або втричі збільшує кількість необхідних перевантажень, залишаючись при цьому менш потужними
• алгоритми на основі діапазону також є композиційними (ви можете складати або ланцюжок адаптерів ітератора, хоча це частіше робиться у функціональних мовах та Python)

Звичайно, є ще одна вагома причина, яка полягає в тому, що для того, щоб стандартизувати STL, було вже багато роботи, і надути його зручними обгортками до його широкого використання не було б великим використанням обмеженого часу комітету. Якщо вас цікавить, ви можете знайти технічний звіт компанії Stepanov & Lee тут

Як зазначалося в коментарях, Boost.Range забезпечує новіший підхід, не вимагаючи змін до стандарту.

Виявляється, є стаття Герба Саттера на цю саму тему. В основному проблема полягає в неоднозначності перевантаження. З огляду на наступне:

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

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

І додаючи наступне:

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

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

Буде важко розрізнити 4і 1правильно.

Концепції, запропоновані, але, зрештою, не включені до C ++ 0x, вирішили б це, і також можна обійти його за допомогою enable_if. Для деяких алгоритмів це взагалі не проблема. Але вони вирішили проти цього.

Тепер, прочитавши всі коментарі та відповіді тут, я думаю, що rangeоб'єкти були б найкращим рішенням. Думаю, я подивлюсь Boost.Range.

В основному спадкове рішення. Концепція ітератора моделюється вказівниками, але контейнери не моделюються на масивах. Крім того, оскільки масиви важко пропустити (взагалі потрібен параметр шаблону нетипового шаблону для довжини, як правило), часто функція має лише покажчики.

Але так, в огляді рішення невірно. Нам краще було б об'єкт діапазону, який можна сконструювати з будь-якого begin/endабо begin/length; Тепер _nнатомість у нас є кілька суфіксальних алгоритмів.

Додавання їх не дасть вам ніякої сили (ви вже можете зробити весь контейнер, зателефонувавши .begin()і .end()самі), і це додало б ще одну річ у бібліотеку, яку слід правильно вказати, додавати в бібліотеки постачальниками, перевіряти, підтримувати, тощо.

Коротше кажучи, його, мабуть, немає, тому що не варто намагатися підтримувати набір додаткових шаблонів лише для того, щоб врятувати користувачів цілих контейнерів від введення одного додаткового параметра виклику функції.

На сьогоднішній день http://en.wikipedia.org/wiki/C++11#Range-based_for_loop є приємною альтернативою std::for_each. Зауважте, немає явних ітераторів:

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

(Натхненно https://stackoverflow.com/a/694534/2097284 .)