Хотелось узнать мнение общественности по поводу следующей фичи.
Реализация стандартных алгоритмов для контейнеров, а не для итераторов, т.е. что бы были определны функции типа

iterator find (std::vector& v, const T& value);

а не

InputIterator find(InputIterator First, InputIterator Last, const T& Value);

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

Я говорю о реализации таких функций, например, на уровне отдела предприятия или для своей домашней библиотеки.
Пока я вижу в таких функциях только положительные моменты. Может кто видит в этом отрицательные моменты? Хотелось бы знать.

Положительные моменты:
1. более высокий уровень абстракции — я буду выражать языком программирования именно то, что хочу сказать, т.е. "выполнить поиск этого элемента в этом векторе", а не "выполнить поиск этого значения в этом диапазоне с начала вектора и до конца". Т.е. в такой ситуации мне совершенно не интересно знать про последовательности. Мне совершенно не интересно знать про функции begin() и end().

2. Сокращение объёма кода, который необходимо писать и сопровождать. Ведь в подавляющем большинстве случаев алгоритмы выполняются именно для контейнеров, а не для последовательностей.

3. Можно специализировать алгоритмы для контейнеров, которые не имеют итераторов, т.о. сохраняя единообразный синтаксис.

Здравствуйте, remark, Вы писали:

Посмотри boost::range.
Здесь пример.

Здравствуйте, CrystaX, Вы писали:

CX>Здравствуйте, remark, Вы писали:

CX>Посмотри boost::range.
CX>Здесь пример.

Да, это то о чём я говорил. Значит это всё таки хорошая идея, раз есть в бусте

Ну все-таки там сами алгоритмы вручную определяются для алгоритмов. А как насчёт, что бы сделать более-менее стандартными сами определения стандартных алгоритмов для контейнеров (диапазонов)?

Кто-нибудь практиковал методичное опередление std::find(), std::replace(), std::for_each() и т.д. для контейнеров? Ил это уже где-то есть готовое?

Здравствуйте, remark, Вы писали:

R>Здравствуйте, CrystaX, Вы писали:

CX>>Здравствуйте, remark, Вы писали:

CX>>Посмотри boost::range.
CX>>Здесь пример.

R>Да, это то о чём я говорил. Значит это всё таки хорошая идея, раз есть в бусте

R>Ну все-таки там сами алгоритмы вручную определяются для алгоритмов. А как насчёт, что бы сделать более-менее стандартными сами определения стандартных алгоритмов для контейнеров (диапазонов)?

R>Кто-нибудь практиковал методичное опередление std::find(), std::replace(), std::for_each() и т.д. для контейнеров? Ил это уже где-то есть готовое?

здесь
Смотреть kafe::algorithm.

R>

Здравствуйте, _nn_, Вы писали:

__>Здравствуйте, remark, Вы писали:

R>>Здравствуйте, CrystaX, Вы писали:

CX>>>Здравствуйте, remark, Вы писали:

CX>>>Посмотри boost::range.
CX>>>Здесь пример.

R>>Да, это то о чём я говорил. Значит это всё таки хорошая идея, раз есть в бусте

R>>Ну все-таки там сами алгоритмы вручную определяются для алгоритмов. А как насчёт, что бы сделать более-менее стандартными сами определения стандартных алгоритмов для контейнеров (диапазонов)?

R>>Кто-нибудь практиковал методичное опередление std::find(), std::replace(), std::for_each() и т.д. для контейнеров? Ил это уже где-то есть готовое?

__>здесь
__>Смотреть kafe::algorithm.


Ну так и что? Кто-нибудь это юзал? Или сам писал?
Кто-нибудь думает, что это Хорошая идея или Плохая?
Или всё пишут std::sort(v.begin(), v.end()) и больше ни о чём не думают?

Здравствуйте, remark, Вы писали:

R>Ну так и что? Кто-нибудь это юзал? Или сам писал?
R>Кто-нибудь думает, что это Хорошая идея или Плохая?
R>Или всё пишут std::sort(v.begin(), v.end()) и больше ни о чём не думают?

Я пишу

std::sort(v.begin(), v.end());

и ни о чём не думаю

Здравствуйте, korzhik, Вы писали:

K>Здравствуйте, remark, Вы писали:

R>>Ну так и что? Кто-нибудь это юзал? Или сам писал?
R>>Кто-нибудь думает, что это Хорошая идея или Плохая?
R>>Или всё пишут std::sort(v.begin(), v.end()) и больше ни о чём не думают?

K>Я пишу
K>

K>std::sort(v.begin(), v.end());
K>

K>и ни о чём не думаю
А можно и макрос налабать будет меньше писанины но правда и понятно меньше...

Здравствуйте, Vutik, Вы писали:

V>А можно и макрос налабать будет меньше писанины но правда и понятно меньше...

А чего макрос, а не шаблон функции?

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Vutik, Вы писали:

V>>А можно и макрос налабать будет меньше писанины но правда и понятно меньше...

E>А чего макрос, а не шаблон функции?
Мне както привычнее ..

Здравствуйте, Vutik, Вы писали:

V>Здравствуйте, Erop, Вы писали:

E>>Здравствуйте, Vutik, Вы писали:

V>>>А можно и макрос налабать будет меньше писанины но правда и понятно меньше...

E>>А чего макрос, а не шаблон функции?
V>Мне както привычнее ..

Как будут выглядеть макросы для этих двух функций? (что бы надо было передавать не итераторы, а один контейнер)

template<class RandomAccessIterator>
void sort(
RandomAccessIterator _First,
RandomAccessIterator _Last
);
template<class RandomAccessIterator, class Pr>
void sort(
RandomAccessIterator _First,
RandomAccessIterator _Last,
BinaryPredicate _Comp
);

R>template<class RandomAccessIterator>
R> void sort(
R> RandomAccessIterator _First,
R> RandomAccessIterator _Last
R> );
что то типа етого:
#define SORT_ALL( CONTAINER) std::sort(CONTAINER.begin(), CONTAINER.end())
R>template<class RandomAccessIterator, class Pr>
R> void sort(
R> RandomAccessIterator _First,
R> RandomAccessIterator _Last,
R> BinaryPredicate _Comp
R> );
По аналогии

Здравствуйте, Vutik, Вы писали:

R>>template<class RandomAccessIterator>
R>> void sort(
R>> RandomAccessIterator _First,
R>> RandomAccessIterator _Last
R>> );
V>что то типа етого:
V>#define SORT_ALL( CONTAINER) std::sort(CONTAINER.begin(), CONTAINER.end())
R>>template<class RandomAccessIterator, class Pr>
R>> void sort(
R>> RandomAccessIterator _First,
R>> RandomAccessIterator _Last,
R>> BinaryPredicate _Comp
R>> );
V>По аналогии

Я не хотел бы видеть в своём коде:

...
std::vector v;
...
SORT_ALL(v);
...

Я хотел бы видеть:

...
std::vector v;
...
std::sort(v);
...

Имеет ли смысл писать функцию ктоторая вызывает только одну другую ??? По моему нет. Хотя каждый сам решает

Здравствуйте, Vutik, Вы писали:

V>Имеет ли смысл писать функцию ктоторая вызывает только одну другую ??? По моему нет. Хотя каждый сам решает
Почему нет? Просто интересно...

Здравствуйте, crable, Вы писали:

C>Здравствуйте, Vutik, Вы писали:

V>>Имеет ли смысл писать функцию ктоторая вызывает только одну другую ??? По моему нет. Хотя каждый сам решает
C>Почему нет? Просто интересно...
Думаеш соптимизирует??? хотя если inline поставить наверно будет тоже самое что и с макросом....
А как по мне так лучше писать по старинке ..... зато всем всё ясно

Здравствуйте, Vutik, Вы писали:

V>Имеет ли смысл писать функцию ктоторая вызывает только одну другую ??? По моему нет. Хотя каждый сам решает

Мои 5копеек:
А ещё, в эту функию можно зайти отладчиком, и если вдруг, в этой функции будет ошибка, то ИДЕ укажит именно на тело функции, и в случае нетривиальной ошибки, — не прийдется изучать вывод препроцессора для поиска ошибка.

Здравствуйте, Vutik, Вы писали:

V>Здравствуйте, crable, Вы писали:

C>>Здравствуйте, Vutik, Вы писали:

V>>>Имеет ли смысл писать функцию ктоторая вызывает только одну другую ??? По моему нет. Хотя каждый сам решает
C>>Почему нет? Просто интересно...
V>Думаеш соптимизирует??? хотя если inline поставить наверно будет тоже самое что и с макросом....


А почему не соптимизирует??? Сотимизирует!
Применять inline, если верить Саттеру, вообще не стоит. А я ему верю.
Объективных причин применять макросы вместо функций нет для таких случаев уже давно нет!


V>А как по мне так лучше писать по старинке ..... зато всем всё ясно


Ну что ж, можешь делать по старинке.

Здравствуйте, Vutik, Вы писали:

V>Имеет ли смысл писать функцию ктоторая вызывает только одну другую ??? По моему нет. Хотя каждый сам решает


Это стандартная практика — библиотека должна обеспечивать удобный интерфейс. Почему у некоторых функций в стандартной библиотеке (например std::string::insert() и её подобные) имеется 3-5 разлиных вариантов? Обычно там реализация одна, а остальные 4 функции просто вызывают первую.

Здравствуйте, Vutik, Вы писали:

V>Здравствуйте, crable, Вы писали:

C>>Здравствуйте, Vutik, Вы писали:

V>>>Имеет ли смысл писать функцию ктоторая вызывает только одну другую ??? По моему нет. Хотя каждый сам решает
C>>Почему нет? Просто интересно...
V>Думаеш соптимизирует??? хотя если inline поставить наверно будет тоже самое что и с макросом....
V>А как по мне так лучше писать по старинке ..... зато всем всё ясно
Может тогда и конейнерами стандартными не пользоваться? Вдруг компилятор не соптимизурует... Делать все через макросы, а шаблоны нафиг.

Я на асме начинал поэтому наверно и привычки такие