Алгоритмы STL, принимающие весь контейнер вместо .begin (), end () в качестве аргумента? - PullRequest
16 голосов
/ 17 ноября 2011

Автономные алгоритмы STL (например, std::count_if) используют пару итераторов.Во всех случаях, когда я их использую (и во всех примерах, которые я видел в Интернете!), Я набираю

std::count_if(myContainer.begin(),myContainer.end(), /* ... */ );

. Есть ли причина, по которой сокращенные шаблоны стиля

std::count_if(myContainer, /* ... */ );

не предусмотрены, учитывая, что более чем не выполняется операция над всем контейнером?Я только что пропустил это?Различен ли ответ для c ++ 11 и c ++ 03?

Ответы [ 4 ]

10 голосов
/ 17 ноября 2011

Есть хороший пост в блоге Херба Саттера, обсуждающий вопрос. Суть в том, что добавление контейнерных перегрузок для алгоритмов может создать неоднозначности, если перегрузка для этого алгоритма с таким же количеством параметров шаблона уже существует. Концепции были предназначены для решения этой проблемы.

2 голосов
/ 16 сентября 2012

Принцип STL и гибкость в основном из-за работы на итераторах вместо контейнеров.Это не большая проблема, вы можете повторно использовать трюк, который я использую с ранних лет:

#define FULL_RANGE(c) (c).begin(), (c).end()

std::copy(FULL_RANGE(c), std::ostream_iterator<c::value_type>(cout, "\n")); 
2 голосов
/ 17 ноября 2011

Одной из причин может быть для обеспечения гибкости для диапазона итератора .Возможно, вам не понадобится когда-нибудь перебирать все элементы:

<iterator> it = myContainer.begin();
it++; // do something
it++; // do something
...
std::count_if(it, myContainer.end(), /* ... */ );

Кроме того, вы всегда можете иметь упаковщик, который сделает это за вас:

template<typename T>
... count_if (T myContainer, ...)
{
  std::count_if(myContainer.begin(), myContainer.end(), /* ... */ );
}
0 голосов
/ 17 ноября 2011

Просто потому, что алгоритмы STL связаны / взаимодействуют с контейнером с использованием итераторов.

...