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

J>>Если у тебя функтор тривиальный — сойдет и boost::lambda/boost::bind (до определенного предела, конечно)
V>Это не СТЛ

со следующей версии и bind, и лямбды — это STL

J>>Ну и, само собой, если семантика работы с контейнером не подходит под for_each — надо просто писать цикл и не сходить с ума,

V>Да. Но народ, начитавшись Саттера, уверен, что for_each — это обязательно, и цикл вместо for_each не допустим ни в коем случае.

Ну это уже просто отсутствие здравого смысла
я использую for_each в двух случаях:
1) то, что я хочу сделать, тривиально и записывается _легко читаемым_ bind или лямбда-выражением (буст, ессно)
2) то, что я хочу сделать, нетривиально и может понадобиться еще где-то и несильно зависит от контекста — тогда это функция или функтор, а в for_each — просто ее вызов.
Во всех остальных случаях я юзаю boost::for_each или прямой цикл (если нужно там счетчики поддерживать, или контекст используется в полный рост, и подобное).

V>Причем for each, сам по себе, очень полезная вещь, наглядная, четко демонстрирующая намерения... но увы, не поддерживаемая синтаксически.
V>Например, конструкция типа


V>

V>foreach Vector::Iterator element in vector  {
V>   element.Display(CurrentMonitor);
V>}
V>

тогда уж foreach Vector::value_type& element in vector
в смысле, если foreach, то зачем нам вообще видеть итераторы

Кстати, Boost.Foreach тоже весьма удобная штука.

V>смотрится безусловно лучше, чем

V>

V>for (Vector::Iterator b = vector.begin(), e = vector.end(); b!=e; ++b) 
    b->Display(CurrentMonitor);
V>

V>Но цикл смотрится в миллион раз лучше, чем

V>

V>std::foreach(vector.begin(), vector.end(), std::bind2nd(CurrentMonitor, std:mem_fun_ref(&ElementType::display))); 
V>/*А здесь еще изволь указать тип элемента!*/
V>

+1
да, это ужас и этот ужас уже deprecated в новом стандарте.

А я для связывания вообще макросами пользуюсь — они решают кучу все еще нерешенных проблем.

You will always get what you always got
  If you always do  what you always did

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

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

M>>Но можно написать свой контейнер который будет работать со стандартными алгоритмами.
P>Очень сильно сомневаюсь что это возможно по стандарту. Во всяком случае по факту не получится совместимо. Возьмите STLport и поглядите сколько там директорий для различных компиляторов

ты хочешь сказать, что невозможно написать MySuperVector, который предоставит пару begin/end?

You will always get what you always got
  If you always do  what you always did

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

M>Я не пытаюсь доказать что STL — отстой. Просто хочу восстановить цепочку рассуждений программиста,который пишет велосипед, вместо использовани STL. Не велосипедничают ведь при конкатенации строк.

На начальной стадии развития некоторые велосипедничают

M>А вот к STL как то привыкнуть не могут.

К STL не нужно привыкать, STL нужно понять. После этого, с большой долей вероятности, можно будет предпологать есть ли тот или иной алгоритм в библиотеке. Всё что нужно будет сделать, это найти его название в справке. Это проще, быстрее и надежнее чем писать велосипеды.

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


M>Но можно написать свой контейнер который юудет работать со стандартными алгоритмами.

И раде чего, ради std::copy, std::find, etc? Тривиальные вещи. Не говоря о том, что они очень generic, т.е. опять ничего не знают о данных котыми управляют, так они еще очень бедные. Я понимаю если бы они вкючали алгоритмы такие как здесь здесь. То что предоставляет STL банальщина, конечно приятно, но зачивать свой контейнер ради стандартного десятка или полутора смыла не вижу.

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

S>И раде чего, ради std::copy, std::find, etc? Тривиальные вещи.

Ни в коем случае. Здесь STL игрет роль интерфейса между контейнерами и алгоритмами. Ктонить пишет алгоритмы и обработчики пользуясь интерфейсом итераторов , ктото свои контейнеры предоставляя итераторы. И после этого они смогут работать вместе не зная ничего друг о друге а только пользуясь концептами предоставленными STL.

Как пример имплементация контейнера хранящего данные во внешней памяти или ДБ.

Roman Odaisky wrote:

> Что за бред? std::vector<X>::iterator вполне может быть X*. PODее не бывает.
А тогда

std::vector<X>::iterator null = std::vector<X>::iterator();

и никуда не денется, обнулит.
вот осталось выяснить верно ли, что

X x;
assert(x.end() != null);

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

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

S>>И раде чего, ради std::copy, std::find, etc? Тривиальные вещи.

M>Ни в коем случае. Здесь STL игрет роль интерфейса между контейнерами и алгоритмами. Ктонить пишет алгоритмы и обработчики пользуясь интерфейсом итераторов , ктото свои контейнеры предоставляя итераторы. И после этого они смогут работать вместе не зная ничего друг о друге а только пользуясь концептами предоставленными STL.

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

>Как пример имплементация контейнера хранящего данные во внешней памяти или ДБ.

Отлично! К примеру, реализация Find_if, для VC:

// TEMPLATE FUNCTION find_if
template<class _InIt,
    class _Pr> inline
    _InIt _Find_if(_InIt _First, _InIt _Last, _Pr _Pred)
    {    // find first satisfying _Pred
    _DEBUG_RANGE(_First, _Last);
    _DEBUG_POINTER(_Pred);
    for (; _First != _Last; ++_First)
        if (_Pred(*_First))
            break;
    return (_First);
    }

это простой цикл поиска по условию. Но, где оповещение о прогрессе, где возможность прервать поиск (только не надо _Pred абьюзить он для этого не создан)? Конечно, в общем случае все эти навороты ненужны, но если я буду запускать этот цикл из под UI и поиск идет 5 минут, то это алгоритм не работает — он завесит картинку. Лучше, если при реализации find_if мы будем знать, что прогон цикла дело долгое, и нужно опевещать о процентах выполнения, алгоритм должен быть прерван. Поэтому алгоритм обязан знать о данных с кем он работает. Вот это и беда STL -- слишком универсальный, библиотека не подходит для реальных данных.

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

Предлагайте альтернативу. А приведенные выше аргументы выглядят странно . "STL не позволяет мне стирать в моей стиральной машине , отстой .."

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

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

M>Предлагайте альтернативу. А приведенные выше аргументы выглядят странно . "STL не позволяет мне стирать в моей стиральной машине , отстой .."

Тема ведь "минусы STL", вот я вам минусы назвал.Для больщих массивов STL не подходит и нужно всегда помнить сколько вы будите там хранить. Когда проекты разрастаются, то прежде небольшие массивы могут о себе дать знать их нужно из STL-ля выводить.

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

Кстати, еще один небольшой минус — блокирование thread-а контейнера при поиске:

всегда нужно писать так

{
   locker()
   find( v.begin(), v.end(), a);
}

Нельзя блокировать только часть вектора, списка и пр.

J>со следующей версии и bind, и лямбды — это STL
Будем ждать Интересно, это автоматически выведет за пределы стандарта наш любимый сановский компилятор? И еще интересно, это приведет к тому, что библиотека безнадежно устареет через пару лет, но будучи включенной в стандарт не сможет измениться?

J>тогда уж foreach Vector::value_type& element in vector
J>в смысле, если foreach, то зачем нам вообще видеть итераторы
Абсолютно согласен. Видишь, до чего людей СТЛ доводит!

J>Кстати, Boost.Foreach тоже весьма удобная штука.
Я ведь Бюст так и не освоил . Так что остается поверить на слово.

J>да, это ужас и этот ужас уже deprecated в новом стандарте.
В смысле? Депрекейтед в смысле не будет пооджерживаться или в смысле, что будет бюст, который все упростит?

J>А я для связывания вообще макросами пользуюсь — они решают кучу все еще нерешенных проблем.
А какого рода макросы?

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

M>>>Но можно написать свой контейнер который будет работать со стандартными алгоритмами.
P>>Очень сильно сомневаюсь что это возможно по стандарту. Во всяком случае по факту не получится совместимо. Возьмите STLport и поглядите сколько там директорий для различных компиляторов

J>ты хочешь сказать, что невозможно написать MySuperVector, который предоставит пару begin/end?
Ваш конечно заработает, там где Вы его напишете. А взять просто взять файл <vector> из одного СТЛ и поместить в другой, здесь у меня сомнения. Хотя и не пробовал

Кстати часто vector выглядит

#include <vector.h>

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

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

J>ты хочешь сказать, что невозможно написать MySuperVector, который предоставит пару begin/end?
http://rsdn.ru/forum/message/2933384.flat.aspx

Автор: Lonely Dog
Дата: 29.04.08

— здесь 2 текста одного алгоритма, второй из vc2005
Различаются они typedef-ами и в обоих нельзя использовать свой тип итератора. Не получится взять в 32-х разрядной платформе итератор на основе 64-х бит (например для отображения файла) поскольку зашиты в алгоритм глобальные типы, с iterator_traits или без.

И в обоих текстах лишние проверки условий.

V>Основной минус STL — наличие гнусного алгоритма for_each. В отсутствии лямбда-выражений и вложенных функций наличие for_each выглядело бы просто тонким издевательством над языком и поводом для остроумия

Кстати, совсем недавно случайно узнал что MSVC 2005 и старше (2008) замечательно копмилирует вот такое:

struct {
    void operator()(const int& a1) {
        std::cout << a1 << " ";
    }
} printeach;
std::vector<int> v1(2, 1);
std::for_each(v1.begin(), v1.end(), printeach);

std::deque<int> d1;
d1.push_back(1);
d1.push_back(2);
std::for_each(d1.begin(), d1.end(), printeach);

Правда, всё равно без наличия замыканий всему этому грош цена

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

P>К STL не нужно привыкать, STL нужно понять. После этого, с большой долей вероятности, можно будет предпологать есть ли тот или иной алгоритм в библиотеке. Всё что нужно будет сделать, это найти его название в справке. Это проще, быстрее и надежнее чем писать велосипеды.

А что значит "понять"? Я вот понять понял, а использовать не рвусь.
Ещё алгоритмы из STL туда сюда. Хотя большинство из них не особо полезные, IMHO. Но контейнеры точно не хочу использовать по любому

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

.>А на кой ты некрофилией занялся?
Да всё равно тему уже дано подняли...

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

J>Стоп, какие мапы с хешами, когда ты хочешь массив массивов?
В MFL, например, массив массивов иметь не накладно...
Но дека -- это же вроде бы последовательность всё-таки?

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

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

J>>Стоп, какие мапы с хешами, когда ты хочешь массив массивов?
E>В MFL, например, массив массивов иметь не накладно...
E>Но дека -- это же вроде бы последовательность всё-таки?
ну да. А массив массивов?
Послушай, у меня создается впечатление, что мы говорим о разных вещах.
Можешь уточнить постановку задачи в целом?

You will always get what you always got
  If you always do  what you always did

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

J>Можешь уточнить постановку задачи в целом?
Зачем так уж сильно нужен контейнер std::deque? Для какой практической задачи?
Для массива массивов удобнее иметь массив, который можно задёшево складывать в массив.
Для FIFO хорошо работает вроде бы циклический буфер.
А для чего очень нужен std::deque? Мне вот вроде бы пока что ни разу не понадобился.

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

M>Куда проще по старинке:

M>

M>for(int i=0;i<N;++i)
M>{
M>   array[i] = i;
M> //
M>}
M>

M> Плюс в 1-м варианте у меня нет счётчика,а здесь есть. В общем так спокойнее — без канатоходства.

если вам нужен счетчик используйте boost::counting_iterator

std::copy(
    boost::counting_iterator<int>(0), boost::counting_iterator<int>(N),
    std::back_inserter(array));

может показаться, что ваш пример более простой, НО:
— array должен содержать как минимум N элементов и за этим надо постоянно следить. Такой код содержит потенциальные ошибки.
— как показывает практика, программисты очень любят дописывать свою логику в такие циклы. Вот ему надо конкретно сейчас, конкретно здесь что-то сделать, — он, не задумываясь, "вбивает колышек", и со временем цикл превращается в спагетти код.
— использование циклов ведет к дублированию кода. Функторы можно использовать повторно.

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

A>Функторы можно использовать повторно.

Старые флеймовые темы тоже можно использовать повторно, но стоит быть готовым к повторному использованию плюсомёта.