Hi All

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

Вот это не удобно, потому что много писать.

for(vector<int>::iterator it = array.begin();it!=array.end();++it)
{
 //
}

for_each() не удобен,поскольку ему нужно передавать функтор/функцию. Я не хочу делать класс/функцию для каждого цикла!

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

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

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

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

_>перечислите, на ваш взгляд, основные минусы STL
_>принимаются только ответы с аргументацией

Довольно подробно разбирается в Technical Report on C++ Performance (Final draft)

Mazay wrote:


> Куда проще по старинке:
>
> for(int i=0;i<N;++i)
> {
> array[i] = i;
> //
> }
>
>
> Плюс в 1-м варианте у меня нет счётчика,а здесь есть. В общем так
> спокойнее — без канатоходства.
А давайте теперь заменим vector на list, а потом на set... и запишем по старинке...
Не забудьте зонтик по канату ходить.

В одном конкретном случае зачастую проще свилосипедствовать, чем разбираться с алгоритмом STL или с особенностями контейнеров. Зачастую быстрее написать алгоритм чем искать его в справочнике (в смысле в хелпе). Кароче надо довольно длинный список в голове держать. Если, скажем, ф-я поиска подстроки есть всегда и везде, то реализовывать её самому мне в голову не придёт, а вот тотже find_if: "ХЗ — есть эта фича в STL или нет — быстрее самому написать. Может я её ещё и не запинаю в своём случае". Нет в СТЛ какой-то структурировнности, что-ли. Какого-то простого правила — "Вот это точно должно быть в СТЛ, а вот это — не стоит и искать там".

ЗЫ
Каквыпонимаете этоя спозиции новичка рассказываю. Со временем конечно появляется какое-то трудноформализуемое чутьё — навык.

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

M>Нет в СТЛ какой-то структурировнности, что-ли. Какого-то простого правила — "Вот это точно должно быть в СТЛ, а вот это — не стоит и искать там".

Это не в STL нет структурированности, а в твоих знаниях оной.

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

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

M>>Нет в СТЛ какой-то структурировнности, что-ли. Какого-то простого правила — "Вот это точно должно быть в СТЛ, а вот это — не стоит и искать там".

KBH>Это не в STL нет структурированности, а в твоих знаниях оной.

Согласен. Только почему-то не я один такой. Наверное потому,что для того что бы сказать что функция next_permutation есть в STL это нужно просто ЗНАТЬ. Ты не можешь об этом догадаться, как например ты можешь не знать, чтоо в boost::filesystem есть функция извлечени пути из полного имени файла, но при этом логично предположить, что она там есть. И в 1-ю очередь я загляну в хелп, ибо вероятность найти там желаеме высока. А в случае с STL ДОГАДАТЬСЯ о наличии там какой-то фичи — проблематично. Если я не уверен что там есть нужный мне алгоритм,то не буду тратить время на штудирование хелпа — я напишу свой, ибо мои поиски могут не увенчаться успехом и я в пустую потрачу драгоценное время. Если конечно передо мной не стоит задача "по максимуму использовать STL".

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

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

M>>Нет в СТЛ какой-то структурировнности, что-ли. Какого-то простого правила — "Вот это точно должно быть в СТЛ, а вот это — не стоит и искать там".

KBH>Это не в STL нет структурированности, а в твоих знаниях оной.

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

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

_>Hi All

_>перечислите, на ваш взгляд, основные минусы STL
_>принимаются только ответы с аргументацией

на заре моей юности мне показалась неудобной и нелогичной работа с filesystem. С тех пор практически не использовал.

Mazay wrote:
> В одном конкретном случае зачастую проще свилосипедствовать, чем
> разбираться с алгоритмом STL или с особенностями контейнеров.
Чего в контейнерах STL такого сложного?

> быстрее написать алгоритм чем искать его в справочнике (в смысле в
> хелпе). Кароче надо довольно длинный список в голове держать. Если,
> скажем, ф-я поиска подстроки есть всегда и везде, то реализовывать её
> самому мне в голову не придёт, а вот тотже find_if
Как ты будешь подстроку в std::map искать?

> Нет в СТЛ какой-то структурировнности, что-ли. Какого-то
> простого правила — "Вот это точно должно быть в СТЛ, а вот это — не
> стоит и искать там".
STL вполне хорошо структурирована. Надо просто понимать идеологию
итераторов — тогда все становится просто и понятно.

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

_>Hi All

_>перечислите, на ваш взгляд, основные минусы STL
_>принимаются только ответы с аргументацией

У STL много минусов (про некоторые из них можно поискать на форуме), но главный минус (из которого вытекают и все остальные) один -- эта библиотека перестала развиваться. По политическим соображениям STL включили в стандарт. Это привело к замораживанию интерфейса библиотеки (который далек от идеального). Конкретные реализации тоже плохо эволюционируют и не в том направлении. Фактически мы имеем дело с мертвой вещью. Ближайший аналог -- MFC.
Использовать мертвую вещь для новых проектов не стоит.
Теперь более конкретно.

1) STL это библиотека алгоритмов и контейнеров.
2) Какие алгоритмы есть в этой библиотеке? Из серьёзных и востребованых -- sort, stable_sort, heap_sort . Всё остальное -- не алгоритмы, а мелкие утилиты, в большинстве бесполезные (типа знаменитого for_each).

sort, stable_sort

Что это за алгоритмы? А никто не знает -- произвол реализации. Хотя в том же Кнуте вагон алгоритмов сортировки.
И библиотека, претендующая на стандартную должна не фиг знает что содержать, а чисто конкретно -- sort 2, sort 3, sort 4, ..., quick sort, merge sort,
intro sort, quick random pivot sort и.т.д.

3) Контейнеры. Все STL контейнеры расчитаны на копирабельные типы. Это огромный минус. Причем совершенно непонятно, зачем такое ограничение. Никаких технических причин для этого нет. Сами контейнеры. Практически единственный мало-мальски полезный класс -- vector. А где списки? Я знаю много разных типов списков. Где они все? А где деревья? RB-tree AVL-tree B-tree ? Похоже, авторам так и не удалось прочитать Кнута. IQ не хватило.

Короче. Диагноз -- халтура. Два балла.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

_>А давайте теперь заменим vector на list, а потом на set... и запишем по старинке...
_>Не забудьте зонтик по канату ходить.

template<class Container>
void doing_some_complex(Container& c)
{
...//здесь у нас контекст
Container::iterator i=c.begin(),endi=c.end();
for(;i!=endi;++i)
{
...//а здесь мы его используем
}
...
}

Проблема не в том как вы обходите контейнер, а в том что писать
функциональный объект (или отдельную функцию) фактически для тела for()
оказывается непрактично
За всё время я наверное раза 2 использовал for_each()

Хотя из этого не следует что он не нужен.

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

C>Mazay wrote:
>> В одном конкретном случае зачастую проще свилосипедствовать, чем
>> разбираться с алгоритмом STL или с особенностями контейнеров.
C>Чего в контейнерах STL такого сложного?
По отдельности — ничего. А вот в целом... Ну почему рядом с map я не нахожу hashmap ? Ну и есть ещё грабли с vector<bool>.

>> быстрее написать алгоритм чем искать его в справочнике (в смысле в
>> хелпе). Кароче надо довольно длинный список в голове держать. Если,
>> скажем, ф-я поиска подстроки есть всегда и везде, то реализовывать её
>> самому мне в голову не придёт, а вот тотже find_if
C>Как ты будешь подстроку в std::map искать?
Не, я имел ввиду то, что я никогда не стану писать функцию поиска подстроки в строке, ибо уверен что всё придумано до нас. А вот наличие find_if'a для меня стало приятной неожиданностью.

>> Нет в СТЛ какой-то структурировнности, что-ли. Какого-то
>> простого правила — "Вот это точно должно быть в СТЛ, а вот это — не
>> стоит и искать там".
C>STL вполне хорошо структурирована. Надо просто понимать идеологию
C>итераторов — тогда все становится просто и понятно.
Понимание идеологии итераторов не даст мне знание всех алгоритмов библиотеки. Их надо просто вызубрить. Ну хотя бы запомнить что алгоритм дл такой-то задачи там точно есть.

Блин, а давайте ещё поспорим на тему "Какие недостатки у С++"
Уверен, ответы будут:

"Я плохо, понимаю С++" ->
"Для того чтобы хорошо знать С++, нужно прочитать много книг, и осознать то, что в них написано" -> "C++ слишком сложный"
-> "Нафига мне нужен такой язык?" -> "возьму я Basic, или ещё лучше напишу свой"

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

C>Mazay wrote:
>> В одном конкретном случае зачастую проще свилосипедствовать, чем
>> разбираться с алгоритмом STL или с особенностями контейнеров.
C>Чего в контейнерах STL такого сложного?

Создатели библиотеки предпочитали вообще не реализовывать некоторые вещщие, если не были уверены в том, что penalty будет минимальным. Естессно такое бывает только в сказках — в результате библиотека создаёт впечатление недоделанной, фрагментированной. Как будто собрались старые приятели и склеили свои велосипеды в одну библиотеку. Что-то есть — хорошо, нет — сами пишите. Благо общее направление движения задано верно: я предпочту написать свой класс, так чтоб он выглядел как часть STL и легко с ней интегрировался.

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

Ш>У STL много минусов (про некоторые из них можно поискать на форуме), но главный минус (из которого вытекают и все остальные) один -- эта библиотека перестала развиваться. По политическим соображениям STL включили в стандарт. Это привело к замораживанию интерфейса библиотеки (который далек от идеального). Конкретные реализации тоже плохо эволюционируют и не в том направлении. Фактически мы имеем дело с мертвой вещью. Ближайший аналог -- MFC.
Что-то больно мрачно.
Ш>Использовать мертвую вещь для новых проектов не стоит.
Ш>Теперь более конкретно.

Ш>1) STL это библиотека алгоритмов и контейнеров.
Ш>2) Какие алгоритмы есть в этой библиотеке? Из серьёзных и востребованых -- sort, stable_sort, heap_sort . Всё остальное -- не алгоритмы, а мелкие утилиты, в большинстве бесполезные (типа знаменитого for_each).

Ш>sort, stable_sort

Ш>Что это за алгоритмы? А никто не знает -- произвол реализации. Хотя в том же Кнуте вагон алгоритмов сортировки.
Ш>И библиотека, претендующая на стандартную должна не фиг знает что содержать, а чисто конкретно -- sort 2, sort 3, sort 4, ..., quick sort, merge sort,
Ш>intro sort, quick random pivot sort и.т.д.
+1

Ш>3) Контейнеры. Все STL контейнеры расчитаны на копирабельные типы. Это огромный минус. Причем совершенно непонятно, зачем такое ограничение. Никаких технических причин для этого нет. Сами контейнеры. Практически единственный мало-мальски полезный класс -- vector. А где списки? Я знаю много разных типов списков. Где они все? А где деревья? RB-tree AVL-tree B-tree ? Похоже, авторам так и не удалось прочитать Кнута. IQ не хватило.

Ш>Короче. Диагноз -- халтура. Два балла.

Жёстко! Хотя я согласен: если делаете библиотеку контейнеров — так делайте её до конца. Даже если что-то будет не очень эффективно никто не мешает пользовтелям отнаследоваться или специализировать шаблон.

Каждый раз натыкаюсь, и каждый раз матерюсь.
Бывает надо написать обощённый класс, который возвращает ссылку на тип,
а контейнер там vector и надо вдруг bool использовать...

... и начинаются подпорки ввиде специализаций и замены
внутреннего типа на какой-нибудь char

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

_>Hi All

_>перечислите, на ваш взгляд, основные минусы STL
_>принимаются только ответы с аргументацией

1) Контейнеры STL не транзакционны. Т.е. если во время операции с контейнером не удалось выделить память, то после этого контейнер находится в неопределнном состоянии — уже не исходное, но еще не конечное. Соответственно типы, которые хранят данные в STL контейнерах тоже не будут транзакционными, если не прилагать специальных усилий и терять при этом эффективность.
2) В случае невозможности выделения памяти контейнеры STL кидают исключение. Стало быть, вызывающий код обязан его обрабатывать. Если вы используете STL в программе, это не так страшно, а вот если пишете библиотеку ф-ций с использованием STL, то тем самым навязываете пользователю то, что он тоже должен обрабатывать исключения. Если Вы используете контейнеры только внутренне и аккуратно обрабатываете все исключения, то тогда еще не все потеряно. А вот если используете типы STL в параметрах ф-ций, тогда плохо дело.

Насколько я знаю, STL, который поставляется с Visual Studio эти недостатки имеет. Было бы интересно узнать, как обстоит дело в остальных реализациях.

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

G>1) Контейнеры STL не транзакционны. Т.е. если во время операции с контейнером не удалось выделить память, то после этого контейнер находится в неопределнном состоянии — уже не исходное, но еще не конечное. Соответственно типы, которые хранят данные в STL контейнерах тоже не будут транзакционными, если не прилагать специальных усилий и терять при этом эффективность.
Не совсем правда. Насколько я помню.
Контейнеры гарантируют компромисс, что выделенная память не будет потеряна, если произошло
исключение, при выделении памяти.
Но транзакционность, т.е. откат в состояние до начала операции, действительно не гарантируют.

Шахтер wrote:
> Где они все? А где деревья? RB-tree AVL-tree
> B-tree ? Похоже, авторам так и не удалось прочитать Кнута. IQ не хватило.
В Boost'е А еще в STL из полезных вещей есть map, string. В принципе,
больше особо ничего и не использую оттуда.

> Короче. Диагноз -- халтура. Два балла.
Вполне нормальная библиотека, ее достоинство в том, что она продвинула в
массу идею разделения алгоритмов и контейнеров.