Я превосходно понимаю что покушаюсь на святое и что скоро-скоро меня накроет залп из тухлых яиц по своей суммарной мощности превосходящий бомбу сброшенную на Хиросиму. Но искушение велико.
Итак, ЗА ЧТО Я НЕ ЛЮБЛЮ STL:
---------------------------------------------------------------------------------
1) За то что его контейнеры реализуют парадигму "владения" только в том случае, когда обьекты хранятся в контейнере "по значению". Для тех кто забыл или не знает — "обьектом владеет тот кто его удаляет".
Пример:
void func1()
{
vector<TheClass> byvalStorage;
while(<<очень много>>) {
byvalStorage.push_back(TheClass());
//вот здесь нас поджидает две совершенно лишних операции, а именно - операция копирования и и операция удаления временного обьекта.
//К тому же выясняется что класс TheClass должен иметь осмысленный конструктор копирования.
}
/*
...
делаем еще много чего
...
*/
/* а вот здесь наш контейнер благополучно самоуничтожается со всем своим содержимым...*/
}
//Конечно, это можно переписать и так:void func2()
{
vector<TheClass*> byrefStorage;
while(<<очень много>>) {
byvalStorage.push_back( new TheClass() );
//и никаких лишних операций...
}
/*
...
делаем еще много чего
...
*/
/*а вот здесь я должен ручками удалить все из контейнера - т.к. гадить в память
никогда не считалось хорошим тоном. А подлый STL за меня это не сделает*/
}
...А хотелось бы мне лишний параметр в шаблон контейнера — что-то типа "I0WNU=true". Конечно, если value_type контейнера не является указателем, этот параметр бесполезен, но в противном случае он просто незаменим. Апологеты STL могут сказать что "владеющий указателями" контейнер не будет совместим с почти всеми алгоритмами (с copy_xx() — точно). Это так, но кто мешает посредством специализации запретить таким алгоритмам работать с "владетельными" контейнерами ?
---------------------------------------------------------------------------------
2) За их строки. Точнее за то что они модель "Sequence", Что мешало Степанову и компании сделать строку также моделью "Front Inserting Sequence" и "Back Inserting Sequence"? Робкие шаги в этом направлении видны (по крайней мере реализовали метод push_back()). Но дальше дело почему-то не пошло...
Чувство это сугубо иррациональное, идущее из глубины моего естества, но тем не менее каждый раз как я обнаруживаю что у строки нет методов "front()" и "back()" и "push_front()" во мне закипает тихое бешенство...
То же самое касается отсутствия строковых специализаций таких полезных вещей как istream_iterator... Скажете что есть getline()? Да идите вы со своими советами
---------------------------------------------------------------------------------
3) За их список. Точнее за его сортировку. А еще точнее — за метод sort(). За каким хреном, позвольте спроcить? Не вы ли договаривались что sort() это АЛГОРИТМ? Ах да, алгоритм "sort" работает только с "Random Access Iterator"... А у списка итератор всего лишь "bidirectional"... Так КАКОГО ЖЕ ЧЕРТА вы не предусмотрели алгоритм sort_for_bidirectional_iterator()?
---------------------------------------------------------------------------------
4) За их потоки. Точнее за исключение "ios_base::failure". А еще точнее — за его конструктор failure::failure(const string&).
Это ЕДИНСТВЕННОЕ место где потоки STL используют string. Нескромный вопрос: зачем? Идиотизм? Про.б? Или что-то еще?
---------------------------------------------------------------------------------
Пожалуй, пока хватит...
____________________
God obviously didn't debug, hasn't done any maintenance, and no documentation can be found. Truly amateur work.
Я тож ее не люблю. Еслиб она была кроссплатформенная. Так нет — на Юних пидется портировать, бо там STL другой троху.
Слишком дыма — слишком много хитрости
TMH>Я превосходно понимаю что покушаюсь на святое и что скоро-скоро меня накроет залп из тухлых яиц по своей суммарной мощности превосходящий бомбу сброшенную на Хиросиму. Но искушение велико.
Все программисты по отношеию к STL делятся на две категории — одни борются с STL, другие счастливо живут без него.
TMH>Итак, ЗА ЧТО Я НЕ ЛЮБЛЮ STL: TMH>--------------------------------------------------------------------------------- TMH>1) За то что его контейнеры реализуют парадигму "владения" только в том случае, когда обьекты хранятся в контейнере "по значению". Для тех кто забыл или не знает — "обьектом владеет тот кто его удаляет".
TMH>Пример: TMH>
TMH>void func1()
TMH>{
TMH> vector<TheClass> byvalStorage;
TMH> while(<<очень много>>) {
TMH> byvalStorage.push_back(TheClass());
TMH> //вот здесь нас поджидает две совершенно лишних операции, а именно - операция копирования и и операция удаления временного обьекта.
TMH> //К тому же выясняется что класс TheClass должен иметь осмысленный конструктор копирования.
TMH> }
TMH> /*
TMH> ...
TMH> делаем еще много чего
TMH> ...
TMH> */
TMH>
TMH> /* а вот здесь наш контейнер благополучно самоуничтожается со всем своим содержимым...*/
TMH>}
TMH>//Конечно, это можно переписать и так:
TMH>void func2()
TMH>{
TMH> vector<TheClass*> byrefStorage;
TMH> while(<<очень много>>) {
TMH> byvalStorage.push_back( new TheClass() );
TMH> //и никаких лишних операций...
TMH> }
TMH> /*
TMH> ...
TMH> делаем еще много чего
TMH> ...
TMH> */
TMH>
TMH> /*а вот здесь я должен ручками удалить все из контейнера - т.к. гадить в память
TMH> никогда не считалось хорошим тоном. А подлый STL за меня это не сделает*/
TMH>}
TMH>
TMH>...А хотелось бы мне лишний параметр в шаблон контейнера — что-то типа "I0WNU=true". Конечно, если value_type контейнера не является указателем, этот параметр бесполезен, но в противном случае он просто незаменим. Апологеты STL могут сказать что "владеющий указателями" контейнер не будет совместим с почти всеми алгоритмами (с copy_xx() — точно). Это так, но кто мешает посредством специализации запретить таким алгоритмам работать с "владетельными" контейнерами ?
TMH>--------------------------------------------------------------------------------- TMH>2) За их строки. Точнее за то что они модель "Sequence", Что мешало Степанову и компании сделать строку также моделью "Front Inserting Sequence" и "Back Inserting Sequence"? Робкие шаги в этом направлении видны (по крайней мере реализовали метод push_back()). Но дальше дело почему-то не пошло... TMH>Чувство это сугубо иррациональное, идущее из глубины моего естества, но тем не менее каждый раз как я обнаруживаю что у строки нет методов "front()" и "back()" и "push_front()" во мне закипает тихое бешенство...
TMH>То же самое касается отсутствия строковых специализаций таких полезных вещей как istream_iterator... Скажете что есть getline()? Да идите вы со своими советами
TMH>--------------------------------------------------------------------------------- TMH>3) За их список. Точнее за его сортировку. А еще точнее — за метод sort(). За каким хреном, позвольте спроcить? Не вы ли договаривались что sort() это АЛГОРИТМ? Ах да, алгоритм "sort" работает только с "Random Access Iterator"... А у списка итератор всего лишь "bidirectional"... Так КАКОГО ЖЕ ЧЕРТА вы не предусмотрели алгоритм sort_for_bidirectional_iterator()?
TMH>--------------------------------------------------------------------------------- TMH>4) За их потоки. Точнее за исключение "ios_base::failure". А еще точнее — за его конструктор failure::failure(const string&).
TMH>Это ЕДИНСТВЕННОЕ место где потоки STL используют string. Нескромный вопрос: зачем? Идиотизм? Про.б? Или что-то еще?
TMH>--------------------------------------------------------------------------------- TMH>Пожалуй, пока хватит...
Здравствуйте Добрый чэчэн Ибрагим, Вы писали:
ДЧИ>Я тож ее не люблю. Еслиб она была кроссплатформенная. Так нет — на Юних пидется портировать, бо там STL другой троху.
ДЧИ>Слишком [много] дыма — слишком много хитрости
TMH>>Я превосходно понимаю что покушаюсь на святое и что скоро-скоро меня накроет залп из тухлых яиц по своей суммарной мощности превосходящий бомбу сброшенную на Хиросиму. Но искушение велико.
Половину тухлых яиц отсылай авторам стандартных библиотек
ДЧИ>Все программисты по отношеию к STL делятся на две категории — одни борются с STL, другие счастливо живут без него.
В результате сэкса с STL под VxWorks — пришлось переписать строки нах.
-- TMH>1) За то что его контейнеры реализуют парадигму "владения" только в том случае, когда обьекты хранятся в контейнере "по значению". Для тех кто забыл или не знает — "обьектом владеет тот кто его удаляет". TMH>...А хотелось бы мне лишний параметр в шаблон контейнера — что-то типа "I0WNU=true". Конечно, если value_type контейнера не является указателем, этот параметр бесполезен, но в противном случае он просто незаменим. Апологеты STL могут сказать что "владеющий указателями" контейнер не будет совместим с почти всеми алгоритмами (с copy_xx() — точно). Это так, но кто мешает посредством специализации запретить таким алгоритмам работать с "владетельными" контейнерами ?
Ты же знаешь ответ. Если хранить в контейнерах не указатели,
а обёртки (умные указатели), то всё не так и грустно. Чем тебе не равится?
Ты привёл пример неудачного использования STL и его с жаром раскритиковал.
Лишний параметр — я против. Это делает указатели какими-то
специальными объектами, снижает равноправие типов, уменьшает логичность и стройность STLя. Заплатка такая получается.Зачем-то логика работы контейнеров раздваивается. А причин-то нет...
А можно реализовать эту заплатку не поступившись ни процентом эффективности?
Удастся соблюсти принцип "Если не пользуешься, то не платишь."?
Про строки... — на всех не угодишь.
Про sort. Да немного нелогично. Но ведь пустяк...
Так что ты это зря. Как говорил старина Эйнштейен: "Всё относитьльно". 8-))
Не нравится по сравнению с чем? Вот это было бы интересно.
Рек>Ты же знаешь ответ. Если хранить в контейнерах не указатели, Рек>а обёртки (умные указатели), то всё не так и грустно. Чем тебе не равится?
Так все равно будет вызываться конструктор копирования, а там создаваться новый экземпляр класса, вокруг которого наш умный указатель оборачивается, так?
Здравствуйте mitroshin, Вы писали:
M>Здравствуйте Рек, Вы писали:
Рек>>Ты же знаешь ответ. Если хранить в контейнерах не указатели, Рек>>а обёртки (умные указатели), то всё не так и грустно. Чем тебе не равится?
M>Так все равно будет вызываться конструктор копирования, а там создаваться новый экземпляр класса, вокруг которого наш умный указатель оборачивается, так?
Не так.
Если ты имеешь контейнер умных указателей (например, vector<CComPtr<MyObj> > )
то при push_back'е копироваться будет только обёртка (умный указатель).
Новый экземпляр указываемого объекта создаваться не будет (только AddRef'ится).
При удалении контейнера обёртки сами удалят (поReleas'ят) указываемые объекты.
Здравствуйте TepMuHyc, Вы писали:
TMH>Я превосходно понимаю что покушаюсь на святое и что скоро-скоро меня накроет залп из тухлых яиц по своей суммарной мощности превосходящий бомбу сброшенную на Хиросиму. Но искушение велико.
Мне больше гнилые помидоры по душе. Сойдет?
TMH>Итак, ЗА ЧТО Я НЕ ЛЮБЛЮ STL: TMH>--------------------------------------------------------------------------------- TMH>1) За то что его контейнеры реализуют парадигму "владения" только в том случае, когда обьекты хранятся в контейнере "по значению". Для тех кто забыл или не знает — "обьектом владеет тот кто его удаляет".
А мне нравится. Я их так и использую. Ну, получаются некоторые накладные расходы — есть такое. Зато я себе раз определил контейнер и складываю в него объектики по значению, а потом они все разом удаляются и мне об этом заботиться не надо.
TMH>--------------------------------------------------------------------------------- TMH>2)... etc...
Здравствуйте Добрый чэчэн Ибрагим, Вы писали:
ДЧИ>Все программисты по отношеию к STL делятся на две категории — одни борются с STL, другие счастливо живут без него.
А я — тихонечко юзаю по мере необходимости... Вывод: Ich bin nicht programmierer! Что в переводе на вольнорусский означает... Ну, мне такое по-русски даже стыдно писать!
Меня всегда удивляет подобная критика! Вы знаете что-то действительно лучше?
Любая библиотека такого размера не будет идеальным образом удовлетворять Вашим требованиям. Вера в то, что существует такая библиотека подобно вере в «серебряную пулю»! Когда у меня было меньше опыта, я считал, что можно написать библиотеку, которая будет много лучше STL, но это была детская болезнь. Теперь я знаю, что можно написать библиотеку, которая будет лучше STL, но для моих конкретных нужд, но не на все случаи жизни, в каких-то случаях она даже будет намного хуже STL (хотя бы тем, что она не так широко распространена).
Из меня не очень хороший защитник STL, так как я ее сам не очень люблю, но не за те мелкие недочеты, а за выхолащивание концепций алокаторов и итераторов. И, несмотря на мое к ней неоднозначное отношение, она намного лучше всего, с чем мне доводилось иметь дело. Ваша критика STL похожа на обывательскую критику С++, Microsoft, COM/OLE и Windows – критика подобного рода абсолютно бессмысленна. Если нет замены этим технологиям, то надо к ним приспосабливаться, а не винить в своих неудачах плохие идеи других людей. Если можете сделать лучше – сделайте и попытайтесь добиться такой же популярности, посмотрим, как будут критиковать Вас.
Теперь пройдемся по пунктам:
TMH>1) За то что его контейнеры реализуют парадигму "владения" только в том случае, когда обьекты хранятся в контейнере "по значению". Для тех кто забыл или не знает — "обьектом владеет тот кто его удаляет".
Здесь уже было сказано правильное решение данной проблемы – умные указатели. Без их использования все равно нельзя написать exception safe код. Так что их надо использовать в любом случае.
TMH>2) За их строки. Точнее за то что они модель "Sequence", Что мешало Степанову и компании сделать строку также моделью "Front Inserting Sequence" и "Back Inserting Sequence"? Робкие шаги в этом направлении видны (по крайней мере реализовали метод push_back()). Но дальше дело почему-то не пошло...
Есть метод insert, который сделает то, что нужно. Есть старая шутка: «реализаций строк существует примерно столько же сколько и программистов». Нельзя написать одну строку на все случаи жизни. Если позволить вставлять символы с двух концов строк со амортизованной сложностью O(1), то не будет совместимости со Строками С, что более важно чем эффективное добавление символов с двух концов (подобная проблема с deque и vector, именно из-за это это два разных класса, а не один).
TMH>3) За их список. Точнее за его сортировку. А еще точнее — за метод sort(). За каким хреном, позвольте спроcить? Не вы ли договаривались что sort() это АЛГОРИТМ? Ах да, алгоритм "sort" работает только с "Random Access Iterator"... А у списка итератор всего лишь "bidirectional"... Так КАКОГО ЖЕ ЧЕРТА вы не предусмотрели алгоритм sort_for_bidirectional_iterator()?
Есть метод sort, он делает свое дело и притом намного эффективнее чем это смог бы сделать внешние алгоритм, работающий через итераторы. А написать такой алгоритм можно и самому, если есть такая потребность. Мне все равно, что вызывать внешний алгоритм, что функцию член, так что это вообще дело вкуса и не более.
TMH>4) За их потоки. Точнее за исключение "ios_base::failure". А еще точнее — за его конструктор failure::failure(const string&). TMH>Это ЕДИНСТВЕННОЕ место где потоки STL используют string. Нескромный вопрос: зачем? Идиотизм? Про.б? Или что-то еще?
Я не знаю почему сделано именно, так но не все ли равно, так как метод what должен возвращать string, так что при наличии строк с счетчиком ссылок, такой подход может быть даже более эффективен чем обычные строки С.
К потокам у меня тоже есть претензии, но они носят концептуальных характер: почему даже потоки узких символов имя принимают имя файла в узких символах, это очень мешает использовать Стандартные потоки в программах работающих только с широкими символами. Более того, не все широкие символы можно превратить в узкие без потерь, так что не все файлы можно открыть, так как может не быть узкого набора символов, в котором можно представить путь к файлу, например, в случае если директории называется по-русски, а файл по-китайски.
Интересно, в какой нибудь из реализаций STL существуют готовые контейнеры для управления объектами со счетчиками ссылок? У меня лично такие есть, и они совместимы с стандартными контейнерами и алгоритмами (я не про vеctor<smart_ptr> — это тупо), но постоянно возникающие вопли об отсутствии оных, наводят на размышления...
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте TepMuHyc, Вы писали:
TMH>4) За их потоки. Точнее за исключение "ios_base::failure". А еще точнее — за его конструктор failure::failure(const string&). TMH>Это ЕДИНСТВЕННОЕ место где потоки STL используют string. Нескромный вопрос: зачем? Идиотизм? Про.б? Или что-то еще?
Тут Вы нас всех ввели в заблуждение, Видимо, никто не помнил, и все поленились посмотреть — я тоже. На самом деле строки используются достаточно широко. Например, класс basic_stringstream и все что с ним связано полностью основано на basic_string. Что же касается исключений то, большая их часть принимает string в качестве параметра, по мимо самого ios_base::failure еще сами классы и все производные от logic_error и runtime_error, то же принимают string в качестве параметра.
Здравствуйте TepMuHyc, Вы писали:
TMH>Итак, ЗА ЧТО Я НЕ ЛЮБЛЮ STL:
Есть одно достоинство в STL, слово STANDARD!
Я видел кучу разных других библиотек шаблонов,
но когда приходиться разбираться где там че , когда тебе нужно всего лишь vector, то за это время можно уже че нибудь свое написать .
Но есть альтернатива, пиши свои методы, свои контейнеры —
но старайся что бы имена и интерфейсы были близки к STL
(хоть они мне иногда и не нравяться ), другому человеку будет проще разобраться.
STL — это стандартная библиотека, которая, соответственно, прошла все круги ада стандартизации, которую все очень хотели закончить побыстрее. Абсолютно никто из ее творцов не говорит, что она является верхом совершенства. Ее еще дорабатывать и дорабатывать. Очень многие вещи, на которые ругаются программисты (в том числе и Вы), обсуждались в процесе стандартизации (тот же push_back, сам конструирующий объект), но комитет не успел прийти к согласию по ним, а сроки поджимали, поэтому приняли как есть.
Или Вас бы больше устроил стандарт С++ без стандартной библиотеки? Только язык?
То, что она есть и она стандартна — само по себе огромное достижение.
А нам всем никто не мешает пользоваться разнообразными примочками к STL, и другими не менее навороченными библиотеками.
И засыпать комитет предложениями о включении Boost в Стандарт.
Здравствуйте jazzer, Вы писали:
J>А нам всем никто не мешает пользоваться разнообразными примочками к STL, и другими не менее навороченными библиотеками.
Мешают тупые компиляторы
J>И засыпать комитет предложениями о включении Boost в Стандарт.
Ха-ха. Половина разработчиков буста вроде как сами комитетчики.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Ну, мля, чувствуется, тебя действительно _достало_ 
ICQ#: 198114726
Перекуём баги на фичи!
, когда тебе нужно всего лишь vector, то за это время можно уже че нибудь свое написать 
.
