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

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

Хотя я бы обобщил его в алгоритм "find_sequence(Start, Stop,
SeqStart,SeqStop)".

> C>STL вполне хорошо структурирована. Надо просто понимать идеологию
> C>итераторов — тогда все становится просто и понятно.
> Понимание идеологии итераторов не даст мне знание всех алгоритмов
> библиотеки. Их надо просто вызубрить. Ну хотя бы запомнить что алгоритм
> дл такой-то задачи там точно есть.
Так какие проблемы? Все алгоритмы стандартной библиотеки умещаются в
пару колонок на листе A4. И в поиске по документации ищутся за секунду.

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

ghostrider wrote:
> 1) Контейнеры STL не транзакционны. Т.е. если во время операции с
> контейнером не удалось выделить память, то после этого контейнер
> находится в неопределнном состоянии — уже не исходное, но еще не
> конечное. Соответственно типы, которые хранят данные в STL контейнерах
> тоже не будут транзакционными, если не прилагать специальных усилий и
> терять при этом эффективность.
Для контейнеров есть несколько операций, для которых гарантирована
"транзакционность" (strong exception guarantee). Ими и надо пользоваться.

А написать транзакционный контейнер в общем случае все равно не получится.

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

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

_>Hi All

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

Отсутствие стандартного hash_map

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


C>А что, кто-то еще передает контейнеры в функции не по константной ссылке?
А причем тут константность ссылки? Она кстати может быть и неконстантная, если функция будет менять содеаржимое. Проблема в другом — используя тип в качестве параметра, ты заставляешь пользователя пользоваться этим типом и пожинать все последствия. Ситуация усугубляется тем, что этот тип определяешь не ты, так что полностью контролировать его поведение не можешь.

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

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

Контейнеры указателей, контейнеры объектов со счетчиками ссылок, контейнеры некопирабельных типов (если я правильно это понимаю) — я сам себе написал и с 2000 года горя не знаю В виде надстройки над std::vector.

Деревья в чистом виде, не знаю зачем мне могли бы понадобиться ... но шаблоны для них и, в конечном итоге, AVL-дерево у меня есть. Единственным основанием существования этого дерева является наличие template-member-ов

template<class U>
 iterator find(const U&);

template<class U>
 bool erase(const U&);

в стандартных std::set/std::map этого нет. Уже пару раз подумывал доработаь и insert до темплейта

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

Да ну, нафиг. На всех не угодишь по любому.

на мой взгляд вырисовалось ещё два минуса...

1. Всё то чего нет в текущей версии stl (прошу меня простить но почемуто под STL имею в виду С++ Standart Library ) но будет в следующей.
2. Это то что stl не охватывает все области... например нет сокетов, threads, GUI, баз данных

Здравствуйте, Шебеко Евгений, Вы писали:

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

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

Например в комбинации со всяческими биндерами бывает крайне полезен

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

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

Не надо далеко ходить... Нет способа преобразовать число в std::string и обратно. Так, чтобы было одновременно быстро, удобно и безопасно.

Здравствуйте, Шебеко Евгений, Вы писали:

ШЕ> Блин, а давайте ещё поспорим на тему "Какие недостатки у С++"

1) Очень сложный язык, очень гибкий, с нереально сложным синтаксисом. Это приводит к тому, что для коллективного программирования на C++ абсолютно необходима инструкция.
А для написания хорошего компилятора нужен довольно большой НИИ

2) Язык C++ очень плохо изолирует программиста от очень низкого уровня. AV, привязка к определённому endian, зависимость от размеров типов, от их выравнивания и т. д. и т. п. -- соверщенно неизбежны при программировании на C++. Для многих задачь это таки лишнее.

3) Провоцирует использование сверхсложных шаблонных конструкций. При чём часто совершенно не по делу.

4) Огромная перегруженность всех механизмов языка. Например:
4а) классы используются для создания типов, похожих на встроенные, для ООП, для реализации парадигмы COM (интерфейсы + объектная модель), для реализации механизмов, для всяких синтаксических трюков и много для чего ещё.
4б) Наследование. Используется для ООП, для выражение отношения "реализует интерфейс", для callbacks (особенно в механизмах распространено), для всяких синтаксических трюков (скажем класс allocated_in_virtual_memory) и опять же много для чего ещё.
Это всё приводит к тому, что часто при чтении программы, особенно чужой и написанной по неизвестнйо тебе инструкции, ты не можешь понять какой именно концепт выражен этой конструкцией языка

Хватит?

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

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

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

Ну, или, вы должны опубликовать свои исхдники и обеспечить работоспособность библиотеки с любой реализацией STL, что тоде небанально. Особенно в области тестирования изделия

E>Так как изделие шаблонное, то оно всюду компилируется заново, поэтому, если вы делаете библиотеку на STL, то вы навязываете пользователю своей библиотеки версию STL, что не всегда удобно пользователям.

E>Ну, или, вы должны опубликовать свои исхдники и обеспечить работоспособность библиотеки с любой реализацией STL, что тоде небанально. Особенно в области тестирования изделия

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

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

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

1) А как тестировать?

E>1) А как тестировать?

Думаю что stl тестировать не надо
А библиотеку на основе stl можно тестировать на одной реализации

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

_>Думаю что stl тестировать не надо
_>А библиотеку на основе stl можно тестировать на одной реализации

А где гарантии?
Например, где гарантии, что нигде не заложлись на особенность реализации?
Например на производительность какого-нибудь метода?

E>А где гарантии?
E>Например, где гарантии, что нигде не заложлись на особенность реализации?
E>Например на производительность какого-нибудь метода?

все гарантии в стандарте...

всё больше не буду опровергать минусы
Буду их только собирать...

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

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

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

Боюсь что на этом её достоинства и исчерпываются.

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

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Да ну, нафиг. На всех не угодишь по любому.

Это вероятно ключевая причина, по которой не удаётся написать всеобъемлющую библиотеку общего назначения.

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

Шахтер wrote:
>> > Короче. Диагноз -- халтура. Два балла.
> C>Вполне нормальная библиотека, ее достоинство в том, что она продвинула в
> C>массу идею разделения алгоритмов и контейнеров.
> Боюсь что на этом её достоинства и исчерпываются.
Мне этого вполне достаточно — свою библиотеку контейнеров я уже написал

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

Ш>3) Контейнеры. Все STL контейнеры расчитаны на копирабельные типы. Это огромный минус.

это элементарно обходится: используй контейнеры на SmartPtr, а сам указатель может быть и некопирабельным.