Здравствуйте, kan_izh, Вы писали:
>> ИМХО, самый большой недостаток — плохо продуманная структура... _>В голове у начинающих программистов?
Начинающих юзать STL _>Потому что одномерный array называется vector, двухмерный array называется matrix. Трёх и более специальных названий не имеют (насколько я знаю).
Лично у меня векторы и матрицы ассоциируются исключительно с математикой...
Одномерный массив — не обязательно вектор... Для вектора в n-мерном пространстве характерно вычисление длины...
>> то ассоциативные — оставляют желать лучшего... >> Подчеркивание того, что множество — ассоциативный контейнер — только с >> толку сбивает начинающего... _>It is a simple associative container because its element values are its key values. _>Просто это так. Что не устраивает? _>К тому же, можно множества одних и тех же элементов строить, но с разным operator<, что в итоге может давать разные _>множества.
Множество, вообще-то, неупорядоченная структура... Искусственно ее упорядочивать — это с толку и сбивает... >> Подчеркивать специфику реализации не стоило и для map — можно было б и _>А если для объекта хаш считать очень неудобно или получится неэффективно?
Не... Хеш — всегда феективней дерева... Просто нужно хеш-функцию подобрать... Вот и порылись бы — столько лет стандарт разрабатывали...
Хотя для map, как правильно заметил Павел Кузнецов ниже — естественная упорядоченность может пригодиться... _>std::hash_map?
Дык его и забыли включить, как пишет Страуструп... И опять же — зачем специфику реализации подчеркивать...
Идея ж — как раз абстрагироваться от реализации, а в STL эти уши торчат из всех щелей... >> А набор алгоритмов — это вообще напорминает свалку... >> А уж про string все написал Саттер в последней книжке — интерфейс >> перегружен до предела... _>С этим согласен.
>> Битовый вектор можно было сделать и динамическим... _>Не понял? std::vector<bool>? А он какой?
Тока операций в нем нифига не реализовано по сравнению с bitset...
>> И похоже на то, что новой редакции STL мы не скоро дождемся... Тока >> вместе со стандартом... _>Юзаем boost, и хватит плакаться.
boost — вообще вся похожа на свалку...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Павел Кузнецов, Вы писали:
>> Подчеркивание того, что множество — ассоциативный контейнер — только с толку сбивает начинающего... ПК>Или, с другой стороны, дает ему в руки более общую "модельку", которая позволит легко запомнить общие моменты set, multiset, bitset, map и multimap без запоминания всех их деталей как было бы, будь они несвязанными компонентами.
Ну, это да... Интерфейс практически один в один (кроме битсета)... Но ведь идея-то — абстрагироваться от конкретной реализации, а в STL эти уши торчаит из всех щелей... >> Подчеркивать специфику реализации не стоило и для map — можно было б и как хеш реализовать... ПК>Гм... В чем, интересно, состояло подчеркивание специфики реализации? А при реализации в виде hash изменилась бы семантика, т.к. порядок перестал бы быть определенным.
Ну, вот с этим действительно можно согласиться... Не могу сходу придумать, но скорее всего естественная сортировка может пригодиться... >> Битовый вектор можно было сделать и динамическим... ПК>Можно. vector<bool> и так динамический.
Тока операций в нем мало... >> И похоже на то, что новой редакции STL мы не скоро дождемся... Тока вместе со стандартом... ПК>Это неизбежное следствие её стандартизации.
Ну, эт понятно...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
>>> то ассоциативные — оставляют желать лучшего... >>> Подчеркивание того, что множество — ассоциативный контейнер — только с >>> толку сбивает начинающего...
LVV>Множество, вообще-то, неупорядоченная структура... Искусственно ее упорядочивать — это с толку и сбивает...
Кстати, а чем отличается множество от того же массива (вектора)? Тем, что в векторе элементы лежат в одном порядке, а во множестве — порядок не определён? Или как? Я вот тоже не понимаю std::set<>.
Здравствуйте, IceStudent, Вы писали:
LVV>>Множество, вообще-то, неупорядоченная структура... Искусственно ее упорядочивать — это с толку и сбивает... IS>Кстати, а чем отличается множество от того же массива (вектора)? Тем, что в векторе элементы лежат в одном порядке, а во множестве — порядок не определён? Или как? Я вот тоже не понимаю std::set<>.
Вообще, если трактовать std::vector<bool> как множество чисел (то есть в множестве есть те из чисел, для которых вектор сожержит true), то порядок тоже не определён.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
IceStudent wrote:
> LVV>Множество, вообще-то, неупорядоченная структура... Искусственно ее > упорядочивать — это с толку и сбивает... > Кстати, а чем отличается множество от того же массива (вектора)? Тем, > что в векторе элементы лежат в одном порядке, а во множестве — порядок > не определён? Или как? Я вот тоже не понимаю std::set<>.
std::set почти тоже самое, что и std::map, но ключ и значение — один и тот же объект (или можно ещё сказать, что
значение всегда эквивалентно ключу). А значит как минимум нужен operator<() для типа. Соответственно, std::set элементы
упорядочены в соответствии с operator<().
Если сравнивать с java.util.Set, то аналогом будет std::hash_set, а аналога std::set в яве, насколько я знаю, нет.
Ну а std::vector — банальный одномерный массив. Больше ничего.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, pavel_turbin, Вы писали:
_>Здравствуйте, Шахтер, Вы писали:
Ш>>3) Контейнеры. Все STL контейнеры расчитаны на копирабельные типы. Это огромный минус.
_>это элементарно обходится: используй контейнеры на SmartPtr, а сам указатель может быть и некопирабельным.
И аллокировать каждый объект в динамической памяти?
Нет, спасибо.
Здравствуйте, gear nuke, Вы писали:
GN>Здравствуйте, Шахтер, Вы писали:
Ш>>главный минус (из которого вытекают и все остальные) один -- эта библиотека перестала развиваться. По политическим соображениям STL включили в стандарт. Это привело к замораживанию интерфейса библиотеки (который далек от идеального).
GN>Верно, (но) это вынужденная мера. Либо иметь 68 велосипедов, либо какой-никакой, но стандарт. Да, из-за этого ценность снижена, но и цена использования тоже. Промышленный накладывает свои отпечатки.
Промышленный -- не значит плохой.
А если значит -- ну его на фик.
Шахтер wrote:
> Ш>>3) Контейнеры. Все STL контейнеры расчитаны на копирабельные типы. > Это огромный минус. > > _>это элементарно обходится: используй контейнеры на SmartPtr, а сам > указатель может быть и некопирабельным. > > > И аллокировать каждый объект в динамической памяти? > Нет, спасибо.
А как ты тогда себе представляешь динамический массив без возможности скопировать элемент?
Вроде только если будут move constructor... это обещают в следующей версии языка... но...
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
G>2) В случае невозможности выделения памяти контейнеры STL кидают исключение. Стало быть, вызывающий код <b>обязан</b> его обрабатывать.
ничего он не обязан. как часто вызывающий код может корректно обработать такую ситуацию? практически никогда.
имхо, страуструп абсолютно прав, предлагая (или, скорее, считая что) использовать исключения (обрабатывать их) не в рамках одного модуля, а на границах модулей, где действительно можно решить данную проблему — например, отключить какую-то функциональность.
у нас в проекте во многих местах есть проверки, что malloc вернет ноль — это лишь откладывает ошибку на некоторое (не такое уж и большое время), а если разрабатывать суперстабильную систему, то все равно нужно как-то обрабатывать подобные исключительные ситуации (тогда какая разница: поймать исключение или проверить результат функции?)... а может вообще vector, например, должен _молча_ выделить столько, сколько сможет и все?!
Не все в этом мире можно выразить с помощью нулей и единиц...
kan_izh wrote: >> И аллокировать каждый объект в динамической памяти? >> Нет, спасибо. > А как ты тогда себе представляешь динамический массив без возможности > скопировать элемент?
Элементы можно перемещать. Даже сейчас, смотри, например, http://www.ddj.com/dept/cpp/184403855
> Вроде только если будут move constructor... это обещают в следующей > версии языка... но...
Ну так я свою библиотеку контейнеров вроде написал
E>если вы делаете библиотеку на STL, то вы навязываете пользователю своей библиотеки версию STL, что не всегда удобно пользователям.
Дык тут проблема не в STL, а в С++ в целом. Вернее, даже не в С++ — а в том что внутри не-managed кода сделать написание межмодульных интерфейсов простым и удобным в общем случае невозможно. В какой-то мере эти задачи пытаются решать на уровне middleware (COM или Corba) — но и в том и в другом случае это попытка скрестить ежа с ужом (к примеру — COM вообще жертвует исключениями в пользу поддержки языков без оных, Corba исключения поддерживает, но юзать её из языков без оных становится занятием для мозахистов).
Здравствуйте, Cyberax, Вы писали:
C>kan_izh wrote: >>> И аллокировать каждый объект в динамической памяти? >>> Нет, спасибо. >> А как ты тогда себе представляешь динамический массив без возможности >> скопировать элемент? C>Элементы можно перемещать. Даже сейчас, смотри, например, C>http://www.ddj.com/dept/cpp/184403855
Перенести указатель внутрь структуры? Но при этом все данные все-равно
в динамической памяти находятся %).
Только при этом еще теряется семантика значения.
Здравствуйте, kan_izh, Вы писали:
_>Шахтер wrote:
>> Ш>>3) Контейнеры. Все STL контейнеры расчитаны на копирабельные типы. >> Это огромный минус. >> >> _>это элементарно обходится: используй контейнеры на SmartPtr, а сам >> указатель может быть и некопирабельным. >> >> >> И аллокировать каждый объект в динамической памяти? >> Нет, спасибо. _>А как ты тогда себе представляешь динамический массив без возможности скопировать элемент? _>Вроде только если будут move constructor... это обещают в следующей версии языка... но...
Некопируемые типы в векторе неуместны, так же как копируемые в node-based контейнерах (map,list)
Более того node-based контейнеры по хорошему должны быть интрузивными, в противном случае они не юзабельные.
Cyberax wrote:
>> > И аллокировать каждый объект в динамической памяти? >> > Нет, спасибо. >> А как ты тогда себе представляешь динамический массив без возможности >> скопировать элемент? > Элементы можно перемещать. Даже сейчас, смотри, например, > http://www.ddj.com/dept/cpp/184403855
Мда уж... Компилятор жалко. Нельзя же так над зверушкой издеваться... гринписа на таких как он и прочих бустовцев нет!
>> Вроде только если будут move constructor... это обещают в следующей >> версии языка... но... > Ну так я свою библиотеку контейнеров вроде написал
А почему невозможно написать свою имплементацию stl, полностью удовлетворяющую стандарту, но со всеми этими mojo и
прочими оптимизациями типа временных string-буферов для str1+str2+...+strN?
Ведь, как я понял, эти mojo-enabled классы вполне будут работать со "старым" кодом, который не "mojo-aware", просто
по-старинке, т.е. медленее из-за временных объектов.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай