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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

Здравствуйте, 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>В этом то и проблема, что это более общее и низкоуровневое решение.

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

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

Здравствуйте, 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, Вы писали:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

char        buf[] = "123456";

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

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

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

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

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

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

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

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

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

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?