Здравствуйте, 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 мы не скоро дождемся... Тока вместе со стандартом...
ПК>Это неизбежное следствие её стандартизации.
Ну, эт понятно...

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

вот интерестно где есть такое? и чтоб всем трём одновременно условиям удовлетворяло?

PS

против "минуса" как такового ни чего против не имею
просто хочется знать где такое бывает...

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

LVV> идея-то — абстрагироваться от конкретной реализации, а в STL эти уши торчаит из всех щелей...

Еще раз спрашиваю: в чем именно состоит подчеркивание специфики реализации, или в новой постановке, какие именно торчат уши?

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

>>> то ассоциативные — оставляют желать лучшего...
>>> Подчеркивание того, что множество — ассоциативный контейнер — только с
>>> толку сбивает начинающего...

LVV>Множество, вообще-то, неупорядоченная структура... Искусственно ее упорядочивать — это с толку и сбивает...
Кстати, а чем отличается множество от того же массива (вектора)? Тем, что в векторе элементы лежат в одном порядке, а во множестве — порядок не определён? Или как? Я вот тоже не понимаю std::set<>.

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


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

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

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

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

M>

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

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

а так ?

for(int i=0; i!=array.size(); ++i)
{
 //
}

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

IID>а так ?
IID>

IID>for(int i=0; i!=array.size(); ++i)
IID>{
IID> //
IID>}
IID>

Ты так на всякий случай загляни в std::vector<>::size(), и учти что это будет вызыватся каждый такт цыкла.

IROV.. wrote:

> IID>for(int i=0; i!=array.size(); ++i)

> Ты так на всякий случай загляни в std::vector<>::size(), и учти что это
Ну так загляни:

size_type size() const
{    // return length of sequence
    return (_Myfirst == 0 ? 0 : _Mylast - _Myfirst);
}

> будет вызыватся каждый такт цыкла.

For many containers, such as vector and deque, size is O(1)

Это тебе не strlen. Так что мимо тазика.

Здравствуйте, 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 — банальный одномерный массив. Больше ничего.

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

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

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

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


И аллокировать каждый объект в динамической памяти?
Нет, спасибо.

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

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

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

Ш>>главный минус (из которого вытекают и все остальные) один -- эта библиотека перестала развиваться. По политическим соображениям STL включили в стандарт. Это привело к замораживанию интерфейса библиотеки (который далек от идеального).

GN>Верно, (но) это вынужденная мера. Либо иметь 68 велосипедов, либо какой-никакой, но стандарт. Да, из-за этого ценность снижена, но и цена использования тоже. Промышленный накладывает свои отпечатки.

Промышленный -- не значит плохой.
А если значит -- ну его на фик.

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

Шахтер wrote:

> Ш>>3) Контейнеры. Все STL контейнеры расчитаны на копирабельные типы.
> Это огромный минус.
>
> _>это элементарно обходится: используй контейнеры на SmartPtr, а сам
> указатель может быть и некопирабельным.
>
>
> И аллокировать каждый объект в динамической памяти?
> Нет, спасибо.
А как ты тогда себе представляешь динамический массив без возможности скопировать элемент?
Вроде только если будут move constructor... это обещают в следующей версии языка... но...

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", просто
по-старинке, т.е. медленее из-за временных объектов.