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

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

О безопасности контейнеров

В STL фактически существует только одна функция-метод, о которой в стандарте явным образом сказано, что она должна генерировать исключение [1-23.1/13]. Речь идет о функции at(), реализующей надежный доступ к элементу вектора или дека. Функция должна генерировать стандартное исключение out_of_range, если аргумент превышает size(). В остальных случаях стандарт требует лишь стандартных исключений вроде bad_alloc при нехватке памяти, или исключений, возникающих при пользовательских операциях. Стандартная библиотека обеспечивает базовую гарантию безопасности исключений: возникновение исключений в стандартной библиотеке не приводит к утечке ресурсов и нарушению контейнерных инвариантов. Более того, многие операции с контейнерами либо вовсе не генерируют исключений, либо обеспечивают транзакционную безопасность: если во время выполнения операции возникнет исключение, то произойдет откат — возврат к состоянию контейнера до начала выполнения операции.
Большинство операций с контейнерами в отношении надежности выполнения можно разделить на 4 класса:

• не генерирует исключений;
  
• либо завершается успешно, либо не вносит изменений;
  
• не генерирует исключений, если они не генерируются при копировании или присваивании элементов (аналогично — при сравнении);
  
• либо завершается успешно, либо не вносит изменений, если при копировании или присваивании не генерируется исключений.

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

1. для списка, множества (мультимножества), отображения (мультиотображения) гарантируется транзакционная безопасность: удаление элемента никогда не завершается неудачей; неудачная попытка вставки оставляет контейнер в прежнем состоянии;
2. для вектора и дека гарантируется транзакционная безопасность операций на концах контейнера; если конструктор копирования и операция присваивания элемента не генерируют исключений, то любые операции с этими элементами либо завершаются успешно, либо не вносят изменений.

Множество и отображения гарантируют только одноэлементную транзакционную безопасность вставки (то есть, либо завершается успешно, либо не вносит изменений), а вот список обеспечивает откат неудачной вставки нескольких элементов. Более того, любые операции (кроме remove(), remove_if(), sort(), merge() и unique()) либо выполняются успешно, либо не вносят изменений. Таким образом, если вам требуется надежный контейнер, используйте список.

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

kan>Есть такая штука — premature optimization.
а есть такая штука — don`t pessimistic

NB>>но то что серьезного конроля типов там нет, это факт.
E>Нахрена он в вычматах?
Фортран, как стандарт, хорошо автоматически распаралеливается некоторыми кластерными системами.
В С++ же приходится делать unroll циклов.

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

Здравствуйте, Erop, Вы писали:
E>>>Имеются в виду автоматические тесты готового изделия? И при этом ещё подразумевается воссоздание всех разнообразных условий компиляции и версий STL ?
_>>всех это уже маразм
_>>обычно ищетсяя компромис
E>всех -- это всех встречающихся у пользователей
На скольких типах процессоров\матерей Вы свою программу тестировали?

ШЕ>Бывает надо написать обощённый класс, который возвращает ссылку на тип,

А вернуть iterator?

>>> kan> А что означает "i < vec.size() — 1", особенно в случае нулевого
>>> размера?
>>> Означает итерировать все кроме последнего. Читается точно так же как и
>>> думается.

написанное выражение данному условию не удовлетворяет

K>Фраза итерировать все кроме последнего сотоит из двух частей.
K>1) итерировать все
K>2) кроме последнего

тогда пиши так ( !vec.empty() && i < vec.size()-1 )

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

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

string? и map?

По моему вообще самые неудобоваримые штуки.

string там должен быть или COW и/или дополнен slice (immutable fragment). Про набор методов я вообще промолчу.

А map? Как хранилище key/value пар? Ну дык hashmap эффективнее.
Или как упорядоченный по ключу набор? И часто такое нужно?

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

Это точно нужно. Для написания абстрактных алгоритмов выпаса сферических коней в виртуальных
континуумах.

В том смысле что далеко не всем выпадает счастье приобщиться к роскоши написания некоего общего алгоритма
для класса контейнеров. Как правило есть контейнер строго определенный и алгоритм один единственный — самый оптимальный.
И времени ёк на то чтобы писать вселенскую абстракцию в стиле stl. Имхо stl уж слишком абстрактно далек от реальных задач.

2 Пётр Седов
Это стеки не в моей программе а от нее в дисассемблере вниз

2 c-smile
>C>массу идею разделения алгоритмов и контейнеров.

Ну я когдато контейнеры на BC читал — сейчас глянул вроде мухи от котлет отдельно. Кажется тогда можно было динамически подсовывать контейне — так далеко абстракции вели. Тоесть во время исполнения хош лист хош вектор.

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

S>Мало квалифицированнах программистов, которые владеют STL.
S>Поэтому код на STL рискует стать трудносопровождаемым.

Если Вы имеете в виду программистов Java или VB, то да — они редко знают STL.
А программист C++, который не владеет STL не должен называться квалифицированным.

За что я не люблю С++

А теперь немного об STL
"Any road followed precisely to it's end leads precisely nowhere"

Dune, Bene Gesserit saying

Не так давно я узнал, когда именно г-ну Степанову пришла идея библиотеки STL — когда он находился в отделении интенсивной терапии (после отравления рыбой) в, как он сам написал, "delirium state", по-просту — в состоянии БРЕДА.

Этот малеьнкий фактик очень удачно вписался в мои собственные представления об STL и самом языка С++. В предельно короткой форме: STL — это просто болезненный бред.

Бред относится к авторам библиотеки, а болезненный — это состояние ее пользователей.

Уже с самого начала STL производит впечатление чего-то монстроидального и совершенно непонятного. Это нагромождение template'd классов (яязык не поворачивается называть их объектами, это просто АТД-переростки) с огромным количество параметров и морем методов с весьма непонятными названиями.
.................................

Hello, Programador!
You wrote on Thu, 15 Feb 2007 19:20:02 GMT:

А есть какие то более аргументированные факты? А то пока все сводится к "не
нравится потому что не нравится".

With best regards, Slava Antonov. E-mail: deadbeef@so.yandex.ru

Programador wrote:

> В предельно короткой форме: STL — это просто болезненный бред.
Надо чуваку boost показать. Тогда он убъёт себя о стенку.

Здравствуйте, Slava Antonov, Вы писали:
SA>А есть какие то более аргументированные факты?
сложность, неэфективность — выше писал.
Еще негибкость — немогу array абстрактного класса сделать. Вон траблы на соседей ветке

Автор: fischer
Дата: 14.02.07

99% потребностей array у Страуструпа на 1 страничке изложено исходники пол экрана.

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

P>Ну я когдато контейнеры на BC читал — сейчас глянул вроде мухи от котлет отдельно. Кажется тогда можно было динамически подсовывать контейне — так далеко абстракции вели. Тоесть во время исполнения хош лист хош вектор.

Слышь, Тореро, я извиняюсь, это на каком языке всё написано?

Здравствуйте, LuciferMoscow, Вы писали:
LM>Покажите мне массив, который может увеличивать свой размер, не требующий памяти их хипа. Я хочу ЭТО увидеть

#include <iostream>

using std::cout;
using std::endl;

template <class T>
void f(size_t cnt) {
  if (!cnt)
    return;
  T arr[cnt];
  cout<<arr[0];
  for (size_t i = 1; i < cnt; ++i)
    cout<<", "<<arr[i];
  cout<<endl;
}

struct tt {
  static int u;
  int i;
  tt() : i (u++) {}
  operator int() const {return i;}
};

int tt::u = 0;

int main(int argc, char* argv[]) {
  f<tt>(atoi(argv[1]));
}

выдача:

D:\Lang\test>g++ -o din_arr din_arr.cpp
D:\Lang\test>din_arr.exe 10
0, 1, 2, 3, 4, 5, 6, 7, 8, 9

g++ (GCC) 3.4.5 (mingw special)

Здравствуйте, remark, Вы писали:
R>Я думаю, я не сильно ошибусь, если скажу, что больше чем половине программистов в 90% случаев хватает возможностей, предоставляемых стандартной библиотекой С++. Если я гружу из БД пару десятков записей и помещаю в контейнер, то абсолютно всё равно в какой контейнер я их помещю и каким sort'ом я их буду сортировать, хоть sort 15, хоть sort 78. Производительности это не прибавит ни на йоту.
R>Ну в оставшихся случаях (когда не хватает возможностей библиотеки) программисту не поможешь, т.к. на все случаи жизни все равно контейнеры и алгоритмы не реализуешь.
Мы сейчас активно используем Python. Одна из прелестей — очень большая библиотека в стандартной поставке:

Строки разбираешь — регекспы есть.
Работа с уникодом и кодировками — да.
HTML/XML — парсеры входят.
Многопоточность — ага.
Операции с операционной системой — конечно.
Сокеты — пожайлуста.
Протоколы над сокетами — все распространенные.
Работа с архивами — zlib, tar, gzip, bzip, zip
Простые базы данных — dumbdbm, dbm, gdbm, беркли
Реляшки — sqlite и стандарт на драйвера.
GUI — TkInter
Даже отладчик и профилер — штатныйе.

Получаються несколько отличные структуры разработки:
На Python-е написал реализацию, тотом смотришь, если где-то стандартный компонент не подходит по каким-то критериям, ищешь замену (или переписываешь).
В эхотаге — ищешь требуемые компаненты (или пишешь сам) — потом пишешь реализацию, в случае, если что-то подходит ищешь замену (или переписываешь).
Т.е. как минимум на один шаг больше.
Кроме того, на первом шаге для эхотага не известны критерии.
К тому же т.к. в python-е очень многое есть в поставке, альтернативы довольно похожи по интерфейсу.
По моему STL-ем пытались решить именно эту проблему.
Сейчас её же пытается решить BOOST...

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

CS> Про набор методов (std::string) я вообще промолчу.
Посмотрите например в MS реализации — size() занимает O(1). Так вот как вы сделаете это без запихивания всех методов внутрь объекта? КАК? Приведите эту реализацию, а мы поглумимся — наверняка какие-нибудь кривости будут. Александреску умен, но у него свои тараканы, нечего их себе в голову пересаживать — не надо написанному верить как истине в последней инстанции. Что-то бесспорно хорошо, а что-то... Кхм, наверно он книгу после работы писал, че не напишешь после 8+ часов перед монитором То что все методы внутри позволяют реализовать size(), end() эффективно — за O(1).

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

>> В предельно короткой форме: STL — это просто болезненный бред.
.>Надо чуваку boost показать. Тогда он убъёт себя о стенку.
Да ладно, boost -- это уже бред не болезненный, а сладострастный. Это когда боль превышает какой-то порог, она начинает приносить практически наркотическое удовольствие

а ты с чем не согласен-то?
с тем, что STL навязывается или с трудностями тестирорвания?