Стандартные алгоритмы для контейнеров - C/C++

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

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

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

A>Понятие последовательности элементов, выражением которого являются итераторы, является более общим, чем понятие конкретного контейнера. Поэтому, более высоким уровнем абстракции является именно использование итераторов. Я обычно вообще не знаю, какой именно контейнер мне нужен, ибо это деталь реализации, которая может меняться по ходу работы. А полагаясь на понятие итератора можно улучшить масштабируемость системы.

Блин, я поражаюсь. А понятие сырой памяти является ещё более общим и, следовательно, (как ты утверждаешь) более высокоуровневым. Давайте всю стандартную библиотеку заточим под использование void*. Зачем мы создаём более удобные контейнеры, итераторы, свои классы для повторного использования? Зачем реализаторам стандартной библиотеки сопровождать все эти объекты?
Зачем существует boost::shared_ptr? Давайте с каждым указателем создавать переменную для подсчёта ссылок. И вручную её везде инкрементировать и декрементировать? А то ведь теперь же надо поддерживать boost::shared_ptr. Это ж сотня строк кода!

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

A>Ну не знаю... Сопровождать надо такой же объём кода: количество букв может быть и разное, но семантика же одна и та же... Даже наоборот, если для всех стандартных алгоритмов написать их версии для конкретных контейнеров, то придётся сопровождать несколько сотен совершенно ненужных функций... А то, что нужно больше печатать: лучше освоить слепой десяти-пальцевый метод набора и эта проблема больше не будет волоновать...

Наводящий вопрос: Зачем нужны библиотеки? Удобные библиотеки?

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

A>Что это за контейнеры, которые не имеют итераторов? Нахрен такие... Или обертки над ними сделать, с нормально определённым понятием итератора (я так и делаю).

Если имеется унаследованный контейнер с итераторами, но которые получаются функциями Start() и End(). Я не хочу каждый раз вспоминать имена этих функций, я опять же хочу просто выполнить алгоритм для этого контейнера.

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

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

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

У многих в прошлом был асм, у меня тоже...
Все мы раньше смотрели чёрно-белый телевизор, давайте и дальше его смотреть, типа цветной как-то непривычно, я к своему чёрно-белому привык

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

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

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

R>>>Абсолютно не согласен. Я работаю с контейнером и не хочу лезть в его внутреннее устройство, не хочу знать ни про какие итераторы. Я хочу применить алгоритм к контейнеру.
R>>>Вызов алгоритма через итераторы на начало и конец контерйнера — это более низкий уровень абстакции.

PC>>Итераторы — это более высокий уровень абстракции, могут существовать итераторы без нонтейнеров. Но не на оборот.
PC>>См. std::ostream_iterator итд

R>Ну вот уже в правильном направлении думаешь

R>Представь себе винтик и автомобиль, что без чего может существовать и что является более высоким уровнем абстракции?
R>Я не хочу каждый раз думать о каждом винтике, я хочу думать об автомобиле. Аналогично, когда я еду на автомобиле, я не хочу даже знать, что машина состоит из винтиков.

Пример не корректен ИМХО

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

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

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

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

Ну не знаю... Сопровождать надо такой же объём кода: количество букв может быть и разное, но семантика же одна и та же... Даже наоборот, если для всех стандартных алгоритмов написать их версии для конкретных контейнеров, то придётся сопровождать несколько сотен совершенно ненужных функций... А то, что нужно больше печатать: лучше освоить слепой десяти-пальцевый метод набора и эта проблема больше не будет волоновать...

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

Что это за контейнеры, которые не имеют итераторов? Нахрен такие... Или обертки над ними сделать, с нормально определённым понятием итератора (я так и делаю).

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

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

Я пишу

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

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

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

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

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

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

R>Абсолютно не согласен. Я работаю с контейнером и не хочу лезть в его внутреннее устройство, не хочу знать ни про какие итераторы. Я хочу применить алгоритм к контейнеру.
R>Вызов алгоритма через итераторы на начало и конец контерйнера — это более низкий уровень абстакции.

Итераторы — это более высокий уровень абстракции, могут существовать итераторы без нонтейнеров. Но не на оборот.
См. std::ostream_iterator итд

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

S>Например, если бы не было интераторов и, соответсвенно, интервальных алгоритмов, а только "контейнерные", как бы выглядел следующий код на

Не хочу спорить про контейнеры и итераторы, думаю нужны и итераторы и диапазоны и контейнеры, но код бы выглядел проще, вот так:

char *p = std::find(buf);

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

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

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

V>>>Откуда find узнает размер???

_>>Например так:
_>>

_>>template<class Item, std::size_t Size>
_>>std::size_t size(T (&)[Size]) { return Size; }
_>>

V>А если буфер через new?

Изначальная идея, что ничего не надо делать. Т.к. для контейнеров код всегда выглядит одинакого:
std::sort(v.begin(), v.end());
...
std::find(v.begin(), v.end(), ...);
...
std::sort(v.begin(), v.end());
...
std::find(v.begin(), v.end(), ...);
...
std::sort(v.begin(), v.end());
...
std::find(v.begin(), v.end(), ...);
...

И так везде.
А при использовании new, код всегда выглядит по разному:
std::sort(p, p + 100);
...
std::find(p, p + MAX_SIZE, ...);
...
std::sort(p, p + sizef(SomeStruct));
...
std::find(p, p2, ...);
И т.д.

Вывод: Если ты решаешь работать через new, то сам решай свой гемморой. Библиотека не будет вычислять размер твоего буфера.
А если ты используешь нормальный контейнер (std::vector), то будет тебе просто и удобно.

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

R>Ну вот уже в правильном направлении думаешь

R>Представь себе винтик и автомобиль, что без чего может существовать и что является более высоким уровнем абстракции?
R>Я не хочу каждый раз думать о каждом винтике, я хочу думать об автомобиле. Аналогично, когда я еду на автомобиле, я не хочу даже знать, что машина состоит из винтиков.

Уж если перейти на автомобильную тематику, то итераторы будут ближе к органам управления — "сцепление, тормоз, газ". Педали на всех авто (итераторы контейнеров) имеют одинаковый интрефейс — прямоугольная площадка

. А уж какие они — механические, гидравлические, с ээлектронным ли приводом, вам как водителю не важно — сел и поехал.

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

Вообще насколько я понимаю, вам просто не нравится писать begin() и end(). Ну не пишите, сделайте обертки к каждому контейнеру кот. пользуетесь.

Вообще хочется услышать мнение по этому поводу местных гуру

— Павла Кузнецова, Андрея Тарасевича, Кодта и др., не в обиду остальным участникам форума.

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

S>Ок, мысль понял, возможно что-то в этом есть, но на самом деле таки выходит
S>что и Вы считаете что работа с алгоритмами через прокси-какой либо является более высоким уровнем абстракции, чем использование алгоритмов, оперирующих контейнером ? -Именно об этом я говорил и пример привел по этой прчине

Вижу, что этот спор плохой. Думаю сама фраза — "высокий/низкий уровен абстракции" несет в себе слишком много смыслов оттенков и т.п.

Скажу так: использовать iterator_range во многих местах (особенно при работе с последовательностями), выглядит логичнее и понятнее, чем просто с iterator и парой begin и end (например при сортировке). Хотя в других местах без просто итераторов не обойтись, например тот же OutputIterator. Если вы попробуете просто перевести все std алгоритмы на iterator_range, то столкнетесь с некоторыми проблемами, так как иногда без iterator не обойтись.

Возможно что базовым понятием нужно считать все таки iterator. Но это не значит что все алгоритмы в стандартной библиотеке должны использовать только базовые понятия и не использовать порожденные, так как, тогда и самим алгоритмам find, sort не место в стандартной библиотеке, про iostream вообще молчу

точно не базовые понятие.

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

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

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

а не

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

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

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

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

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

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

Здравствуйте, 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()) и больше ни о чём не думают?

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

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

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

K>Я пишу
K>

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

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

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

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

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

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

Мне както привычнее ..

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, 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> );
По аналогии

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, 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);
...

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Почему нет? Просто интересно...

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

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

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

C>Почему нет? Просто интересно...
Думаеш соптимизирует??? хотя если inline поставить наверно будет тоже самое что и с макросом....
А как по мне так лучше писать по старинке ..... зато всем всё ясно

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

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

C>>Почему нет? Просто интересно...
V>Думаеш соптимизирует??? хотя если inline поставить наверно будет тоже самое что и с макросом....

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

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

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

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

C>Может тогда и конейнерами стандартными не пользоваться? Вдруг компилятор не соптимизурует... Делать все через макросы, а шаблоны нафиг.

Перегибать не нужно ... но и плодить функции из одной строки по моему не стоит.... моё личное мнение.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

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

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1871.html

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

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

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

Абсолютно не согласен. Я работаю с контейнером и не хочу лезть в его внутреннее устройство, не хочу знать ни про какие итераторы. Я хочу применить алгоритм к контейнеру.
Вызов алгоритма через итераторы на начало и конец контерйнера — это более низкий уровень абстакции.

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

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

R>>Абсолютно не согласен. Я работаю с контейнером и не хочу лезть в его внутреннее устройство, не хочу знать ни про какие итераторы. Я хочу применить алгоритм к контейнеру.
R>>Вызов алгоритма через итераторы на начало и конец контерйнера — это более низкий уровень абстакции.

PC>Итераторы — это более высокий уровень абстракции, могут существовать итераторы без нонтейнеров. Но не на оборот.
PC>См. std::ostream_iterator итд

Ну вот уже в правильном направлении думаешь

Представь себе винтик и автомобиль, что без чего может существовать и что является более высоким уровнем абстракции?
Я не хочу каждый раз думать о каждом винтике, я хочу думать об автомобиле. Аналогично, когда я еду на автомобиле, я не хочу даже знать, что машина состоит из винтиков.

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

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

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

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

R>>>>Абсолютно не согласен. Я работаю с контейнером и не хочу лезть в его внутреннее устройство, не хочу знать ни про какие итераторы. Я хочу применить алгоритм к контейнеру.
R>>>>Вызов алгоритма через итераторы на начало и конец контерйнера — это более низкий уровень абстакции.

PC>>>Итераторы — это более высокий уровень абстракции, могут существовать итераторы без нонтейнеров. Но не на оборот.
PC>>>См. std::ostream_iterator итд

R>>Ну вот уже в правильном направлении думаешь

R>>Представь себе винтик и автомобиль, что без чего может существовать и что является более высоким уровнем абстракции?
R>>Я не хочу каждый раз думать о каждом винтике, я хочу думать об автомобиле. Аналогично, когда я еду на автомобиле, я не хочу даже знать, что машина состоит из винтиков.

S>Пример не корректен ИМХО

Пример абсолютно корректен.

S>Все как-то забыли, что интервальны алгоритмы есьт не просто так, а потому, что это более общее решение.
S>И если вспомнить что нужно предоставить возможность не только работать со всеми элементами контейнера, но и с их подмножеством, как сразу все становиться на свои места

В этом то и проблема, что это более общее и низкоуровневое решение. Возможность работать с последовательностью естественно надо оставить, это я уже писал. Но в то же время надо дать более высокоуровневые и удобные средства работы.

Если следовать твоим взглядам, то у функции std::basic_string::insert() надо оставить только сигнатуру:
template<class InputIterator>
void insert(
iterator _It,
InputIterator _First,
InputIterator _Last
);
как наиболее общую, а все остальные убрать.

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

S>>Пример не корректен ИМХО

R>Пример абсолютно корректен.

У Вас есть возможность ездить отдельно на некоторых винтиках вышей машины ?
И как часто Вы ездите на части своей машины ?
Насколько штатная ситуация — езда на части автомобиля ?
Ваши друзья ездят на чатях автомобилей ?

S>>Все как-то забыли, что интервальны алгоритмы есьт не просто так, а потому, что это более общее решение.
S>>И если вспомнить что нужно предоставить возможность не только работать со всеми элементами контейнера, но и с их подмножеством, как сразу все становиться на свои места

R>В этом то и проблема, что это более общее и низкоуровневое решение.

Не кажется ли Вам что уже в Этом, данном Вами заключени скрыт нонсенс: Общее есть более низкоуровневое ?

ИМХО обобщение — есть переход в уровень абстракций, т.е. на более высокий уровень

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

S>>>Пример не корректен ИМХО

R>>Пример абсолютно корректен.

S>У Вас есть возможность ездить отдельно на некоторых винтиках вышей машины?

Не ездить, а использовать. Да, есть.

S>И как часто Вы ездите на части своей машины ?
S>Насколько штатная ситуация — езда на части автомобиля ?
S>Ваши друзья ездят на чатях автомобилей ?

Механик в автосервисе может разбирать машину хоть до винтиков. Друг, которому не лень, может интересоваться и что-то делать с отдельными частями машины.
А меня, если я не хочу, не должны заставлять знать, интересоваться и что-то делать с отдельными частями.

S>>>Все как-то забыли, что интервальны алгоритмы есьт не просто так, а потому, что это более общее решение.
S>>>И если вспомнить что нужно предоставить возможность не только работать со всеми элементами контейнера, но и с их подмножеством, как сразу все становиться на свои места

R>>В этом то и проблема, что это более общее и низкоуровневое решение.

S>Не кажется ли Вам что уже в Этом, данном Вами заключени скрыт нонсенс: Общее есть более низкоуровневое ?
S>ИМХО обобщение — есть переход в уровень абстракций, т.е. на более высокий уровень

Т.е. ты считаешь, что код, который в приложении работает с объектами в БД — это высокоуровневый код, а код, который реализует, например, веб-службу — это низкоуровневый код?

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

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

PC>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1871.html
Этот полная копирка с Boost Range. Который еще содержит ошибки в коде и в дизайне. Например, почему нет доступа к ссылке на begin и end. Лично мне бы понравилось итерировать так:

for(sub_range<Container> R(C); !R.empty(); ++R.ref_begin())
{
  ... R.begin() ...
}

Зачем const_begin, const_iterator и т.п.? Плодить монстров?

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

Я, в целом, не против "контейнерных" алгоритмов.
Но я имею что сказать:
Итераторы самодостаточны для алгоритмов, а именно, ИМХО использование итераторов делает алгоритмы более абстрактными, если так можно сказать.

Например, если бы не было интераторов и, соответсвенно, интервальных алгоритмов, а только "контейнерные", как бы выглядел следующий код на С++:

...
    char        buf[] = "123456";

    char* p = std::find(
                        buf,
                        buf + sizeof buf,
                        '4'
                    );
...

Соответсвенно возникает вопрос верно ли Ваше утверждение:

Вызов алгоритма через итераторы на начало и конец контерйнера — это более низкий уровень абстакции.

Ведь в приведенном мной примере — контейнера нет вообще, а интервальный алгоритм работать может, кроме того, он еще и правильно работает, и при этом — эот Стандартноне поведение, которое в очередной раз показывает "Не дураки стандарт писали"

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

_>Не хочу спорить про контейнеры и итераторы, думаю нужны и итераторы и диапазоны и контейнеры, но код бы выглядел проще, вот так:
_>

_>char *p = std::find(buf);
_>

Насчет простоты — не возражаю, было бы проще

Я, в целом, не против "контейнерных" алгоритмов.

А какая бы понадобилась сигнатура функции find для buf из моего примера ?

char        buf[] = "123456";

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

S>>Например, если бы не было интераторов и, соответсвенно, интервальных алгоритмов, а только "контейнерные", как бы выглядел следующий код на

_>Не хочу спорить про контейнеры и итераторы, думаю нужны и итераторы и диапазоны и контейнеры, но код бы выглядел проще, вот так:
_>

_>char *p = std::find(buf);
_>

Откуда find узнает размер???

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

S>Насчет простоты — не возражаю, было бы проще

Угу, причем итератор и диапазон итераторов и последовательности и контейнеры не взаимоисключают друг друга. Просто для основной массы алгоритмов используеться не один итератор, а пара (begin, end), т.е. диапазон, который к тому же может обладать свойствами контейнера, т.е. begin(), end(), empty(), size(). Честно говоря, я вообще не понимаю, о чем разговор? Тут делать надо или не делать, и обсуждать конкретные детали, а не спорить кто первее — курица или яйцо.

S>А какая бы понадобилась сигнатура функции find для buf из моего примера ?
S>

S>char        buf[] = "123456";
S>

Например так:

template<class Range>
typename iterator<Range>::type find(Range &X);

template<class Range>
typename iterator<const Range>::type find(const Range &X);

А я вот молчал, молчал и решил сказать.

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

Гораздо интереснее было бы наверно сделать некий объект, с которым можно было бы работать как с множеством, а потом использовать в качестве итераторов. Я это представляю себе приблизительно следующим образом:

std::vector<int> v1;
// здесь заполняем v1

std::range r1=std::make_range(v1.begin(), v1.end()), r2=std::make_range(v1.begin(), v1.end());
r1.remove_if(is_even);
r2.randomize();

std::range r3 = r1.intersect(r2);

std::vector<int> v3;
std::copy(r3.begin(), r3.end(), std::back_inserter(v3));

Опять же не понято насколько это нужно, т.к. во-первых есть версии стандартных алгоритмов принимающих предикат, и, во-вторых, (лично мне) не понятно нсколько функциональным будет такое решение.

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

V>Откуда find узнает размер???

Например так:

template<class Item, std::size_t Size>
std::size_t size(T (&)[Size]) { return Size; }

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

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

V>>Откуда find узнает размер???

_>Например так:
_>

_>template<class Item, std::size_t Size>
_>std::size_t size(T (&)[Size]) { return Size; }
_>

А если буфер через new?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>А если буфер через new?

char *P = new char[PSize];
...
sort(make_range(P, P + PSize));

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

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

S>Я, в целом, не против "контейнерных" алгоритмов.
S>Но я имею что сказать:
S> Итераторы самодостаточны для алгоритмов, а именно, ИМХО использование итераторов делает алгоритмы более абстрактными, если так можно сказать.

S> Например, если бы не было интераторов и, соответсвенно, интервальных алгоритмов, а только "контейнерные", как бы выглядел следующий код на С++:
S>

S>...
S>    char        buf[] = "123456";

S>    char* p = std::find(
S>                        buf,
S>                        buf + sizeof buf,
S>                        '4'
S>                    );
S>...     
S>

S>Соответсвенно возникает вопрос верно ли Ваше утверждение:
S>

S>Вызов алгоритма через итераторы на начало и конец контерйнера — это более низкий уровень абстакции.

S>Ведь в приведенном мной примере — контейнера нет вообще, а интервальный алгоритм работать может, кроме того, он еще и правильно работает, и при этом — эот Стандартноне поведение, которое в очередной раз показывает "Не дураки стандарт писали"

Читай внимательнее первый пост

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

_>Например так:
_>

_>template<class Range>
_>typename iterator<Range>::type find(Range &X);

_>template<class Range>
_>typename iterator<const Range>::type find(const Range &X);
_>

Ок, мысль понял, возможно что-то в этом есть, но на самом деле таки выходит
что и Вы считаете что работа с алгоритмами через прокси-какой либо является более высоким уровнем абстракции, чем использование алгоритмов, оперирующих контейнером ? -Именно об этом я говорил и пример привел по этой прчине

Range — это неплохо имхо, этакий сахарок

... << RSDN@Home 1.1.4 stable rev. 510>>

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

R>Читай внимательнее первый пост

Вы писали про интервальные алгоритмы:

В этом то и проблема, что это более общее и низкоуровневое решение. Возможность работать с последовательностью естественно надо оставить, это я уже писал. Но в то же время надо дать более высокоуровневые и удобные средства работы.

И именно поэтому я и привел такой пример, мой ответ
Я ответил здесь

... << RSDN@Home 1.1.4 stable rev. 510>>

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

V>>А если буфер через new?

_>

_>char *P = new char[PSize];
_>...
_>sort(make_range(P, P + PSize));
_>

Я, как уже писал, не против идеи Рандж,
но в частном конкретном случае — этот код, Вы считаете лучше чем и эффективней чем:

std::find( buf, buf + sizeof buf, '4' );

Я думаю, в споре начала теряться истина, при разработке STL учитывалость не отлько удобство, но эффективность.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

PC>>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1871.html
_>Этот полная копирка с Boost Range. Который еще содержит ошибки в коде и в дизайне. Например, почему нет доступа к ссылке на begin и end. Лично мне бы понравилось итерировать так:
Ну это пропозал от автора boost.range

А для ошибок будет proposal Range Library Proposal (Revision 1)

_>for(sub_range<Container> R(C); !R.empty(); ++R.ref_begin())
_>{
_>  ... R.begin() ...
_>}
_>

Пиши обертку и радуйся, но уже есть стандартный способ, и всё (надеюсь) будут пользовать именно его.

А еще (пример из C#) ???

while (c.MoveNext())
{
    cout << c.Read();
}

_>Зачем const_begin, const_iterator и т.п.? Плодить монстров?
Абсолютно правильно, как без доступа read-only? Глянь кстати на boost.iterators — новый подход к итераторам.

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

Согласен здесь

... << RSDN@Home 1.1.4 stable rev. 510>>

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

_>>

_>>char *P = new char[PSize];
_>>...
_>>sort(make_range(P, P + PSize));
_>>

S>Я, как уже писал, не против идеи Рандж,
S>но в частном конкретном случае — этот код, Вы считаете лучше чем и эффективней чем:

S>

S>std::find( buf, buf + sizeof buf, '4' );
S>

Нет, не считаю эффективнее. Но, считаю что обрабатывать контейнер, который сохранен в обычном указателе — плохой стлиь.

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

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

_>>>

_>>>char *P = new char[PSize];
_>>>...
_>>>sort(make_range(P, P + PSize));
_>>>

S>>Я, как уже писал, не против идеи Рандж,
S>>но в частном конкретном случае — этот код, Вы считаете лучше чем и эффективней чем:

S>>

S>>std::find( buf, buf + sizeof buf, '4' );
S>>

_>Нет, не считаю эффективнее.
Ок

_>Но, считаю что обрабатывать контейнер, который сохранен в обычном указателе — плохой стлиь.

Не вижу ничего плохого, специально так и задумывалось умными людьми из комитета, да и не только из него.

Но это философия

... << RSDN@Home 1.1.4 stable rev. 510>>

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

_>>Нет, не считаю эффективнее.
S>Ок

_>>Но, считаю что обрабатывать контейнер, который сохранен в обычном указателе — плохой стлиь.
S>

Не вижу ничего плохого, специально так и задумывалось умными людьми из комитета, да и не только из него.

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

iterator_range<char *> C = make_iterator_range(new char[PSize], PSize);
...
sort(C);
...
find(C, ...);
...
lexicographical_compare(C, B);

а не такой:

char *P = new char[PSize];
...
sort(P, P + PSize);
...
find(P, P +PSize, ...);
...
lexicographical_compare(P, P + PSize, PB, P + PBSize);

К тому же вероятность появление багов в последнем — гораздо выше. Вот например в последней строке сидит багина, на глаз сразу не заметная.

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

_>>

_>>for(sub_range<Container> R(C); !R.empty(); ++R.ref_begin())
_>>{
_>>  ... R.begin() ...
_>>}
_>>

PC>Пиши обертку и радуйся, но уже есть стандартный способ, и всё (надеюсь) будут пользовать именно его.

Не спорю. Уже написал и радуюсь, при этом boost::range оказался абсолютно бесполезным, так как обертка его прекрасно заменяет

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

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

R>>Читай внимательнее первый пост

S>Вы писали про интервальные алгоритмы:
S>

S>В этом то и проблема, что это более общее и низкоуровневое решение. Возможность работать с последовательностью естественно надо оставить, это я уже писал. Но в то же время надо дать более высокоуровневые и удобные средства работы.

S>И именно поэтому я и привел такой пример, мой ответ
S>Я ответил здесь

Я имел в виду, что:
1. buf — контейнер из 6 байт, т.ч. контейнер тут есть. Если бы ничего не хранило объекты, то не к чему было бы и применять алгоритм.
2. Если программист хочет гемморой, используя голую память, то пусть сам и разбирается. Вычислять размер буфера по указателю библиотека не должна. Но не заставлять каждый раз писать "v.begin(), v.end()" она может.
Если сделать поиск по большому проекту на эту строку "*.begin(), *.end()", то в нём будет до фига таких мест. А с голой памятью всегда по разному вычисляется размер буфера.

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

_>>Зачем const_begin, const_iterator и т.п.? Плодить монстров?
PC>Абсолютно правильно, как без доступа read-only? Глянь кстати на boost.iterators — новый подход к итераторам.

Этот "новый" подход давно видел. А read-only делаеться элементарно iterator<const Container>::type. А const_iterator бесполезная штука.

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

Ладно, контрпример: представим что мы не только сортируем этот массив, а делаем еще кучу операций (как обычно), тогда я буду считать эффективным такой код:
_>

_>iterator_range<char *> C = make_iterator_range(new char[PSize], PSize);
_>...
_>sort(C);
_>...
_>find(C, ...);
_>...
_>lexicographical_compare(C, B);
_>

_>а не такой:
_>

_>char *P = new char[PSize];
_>...
_>sort(P, P + PSize);
_>...
_>find(P, P +PSize, ...);
_>...
_>lexicographical_compare(P, P + PSize, PB, P + PBSize);
_>

Эффективным спорный вопрос, намного более читабельным — это да, это согласен.
А эффективномть в Вашем случае будет зависить от компилятора

_>К тому же вероятность появление багов в последнем — гораздо выше. Вот например в последней строке сидит багина, на глаз сразу не заметная.

ТО же самой что и

   some_container   c, b;
     lexicographical_compare(c.begin(), c.end(), c.begin(), b.end());

Но тем не менее согласен, что код читабельней и более "дюрабильный".
Но сам я ни разу такой ошибки не допустил ни с указателем, ни с итератором

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

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

R>>>Читай внимательнее первый пост

S>>Вы писали про интервальные алгоритмы:
S>>

S>>В этом то и проблема, что это более общее и низкоуровневое решение. Возможность работать с последовательностью естественно надо оставить, это я уже писал. Но в то же время надо дать более высокоуровневые и удобные средства работы.

S>>И именно поэтому я и привел такой пример, мой ответ
S>>Я ответил здесь

R>Я имел в виду, что:
R>1. buf — контейнер из 6 байт, т.ч. контейнер тут есть. Если бы ничего не хранило объекты, то не к чему было бы и применять алгоритм.
R>2. Если программист хочет гемморой, используя голую память, то пусть сам и разбирается. Вычислять размер буфера по указателю библиотека не должна. Но не заставлять каждый раз писать "v.begin(), v.end()" она может.
R>Если сделать поиск по большому проекту на эту строку "*.begin(), *.end()", то в нём будет до фига таких мест. А с голой памятью всегда по разному вычисляется размер буфера.

Ок, итераторы более абстрактны чем непосредственное использование в Алгоритмах, но при этом, я согласен, что реализация диапазонных и контейнерных алгоритмов — имею право на существование, но добавлю ИМХО чай тоже люблю с сахаром

... << RSDN@Home 1.1.4 stable rev. 510>>

От:	remark	http://www.1024cores.net/
Дата:	26.10.05 07:10
Оценка:	+1 -2

От:	CrystaX	https://crystax.me/
Дата:	21.10.05 19:50
Оценка:	2 (2)

От:	remark	http://www.1024cores.net/
Дата:	25.10.05 08:39
Оценка:	+1

	От:	srggal
	Дата:	25.10.05 14:07
	Оценка:	+2

	От:	archimag
	Дата:	26.10.05 05:09
	Оценка:	+2

	От:	Pavel Chikulaev
	Дата:	25.10.05 13:11
	Оценка:	+1

От:	sergey_shandar	http://getboost.codeplex.com/
Дата:	26.10.05 06:06
Оценка:

От:	_nn_	www.nemerleweb.com
Дата:	22.10.05 08:15
Оценка: