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

ustl library — если вы вставите ее в свою программу вместо стандартного STL, очень вероятно, что ваша программа будет компилироваться намного быстрее и генерировать меньше кода.

Тесты я, естественно, не проводил. Как вы правильно заметили, мои утверждения — голословны. Дело в том, что я не пытаюсь идти войной против STL. Мной движет исключительно практический интерес. Я пытаюсь объективно оценить достоинства и недостатки этой библиотеки (или, правильнее говорить, этого стандарта) в применении к моему проекту, чтобы решить, продолжать ли мне использовать ее при разработке новых модулей проекта или нет.

Сейчас я оцениваю преимущества и недостатки библиотеки Boost для использования в моем проекте. Дело в том, что STL — это одно, а STL + Boost — уже совсем другое.

А>Так же просьба уточнить смысл выражения "реализации STL, которые компилируются". Это компиляция '*.cpp' используемых реализацией или что-то другое?

Речь идет о скорости компиляции кода, в котором используется STL.

А>>Что ж поделаешь, нет в мире совершенства. Это, по-моему, чуть ли не единственный ляпсус в этой библиотеке. В целом, филологический уровень библиотеки классов .Net выше, чем у многих других библиотек.

RO>С этим тебе в другой флейм: http://rsdn.ru/forum/message/3229054.1.aspx

Автор: Qbit86
Дата: 26.12.08

Да, у Джавы библиотека тоже ничего (в филологическом плане).

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

А>5) Плохой синтаксис и странные идентификаторы. Я слышал от многих программистов удивление по поводу того, почему в STL’е массив называется «vector», а не «array». Еще примеры: «front» и «back» вместо «first» и «last»; «push_back» вместо, например, «add» или «add_item», или «append»; «size» вместо «count» или «items_count»; «erase» вместо «delete» или «remove». Кстати, образцом в этом отношении я считаю библиотеку классов .Net. Кроме того, неудобно то, что итератор сам не может определять конец итерации. Это приводит к более сложной и менее понятной записи, а также повышает вероятность совершения ошибки.

remove() и erase() — это разные вещи

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

B>remove() и erase() — это разные вещи

Очень очень ценное новое и оригинальное замечание, чтобы поднять ветку от 23.08.06...

Некропостеры!!!

начнем тогда второй круг пожалуй

за что хочется послать отдельный луч поноса в комитет, так это за то что stl проектировалась без оглядки на реальные условия в которых находится С++ программист.
возьмем например map<string,foo> в котором мы по строке ищем foo. на бумаге все прекрасно, но что делать когда в качестве ключей в программе не std::string, а сишные строки возвращаемые например функциями ОС? в этом случае map::find будет из сишной строки лепить временную std::string дергая malloc\free. В итоге на ровном месте получаем чудовищное падение производительности из-за того, что в stl не удосужились слепить шаблонный map::find употребляющий произвольный тип ключа.

такой дизайн — откровенная халтура, что впрочем неудивительно для вещей которые пишутся для других, а не для себя.
ближайший пример аналогичной халтуры — mfc, где афторы тупо копипастили виндовый апи и в результате имеется зоопарк из функций ResetContent, DeleteAllItems делающих одно и то же.

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

K>начнем тогда второй круг пожалуй

K>за что хочется послать отдельный луч поноса в комитет, так это за то что stl проектировалась без оглядки на реальные условия в которых находится С++ программист.
K>возьмем например map<string,foo> в котором мы по строке ищем foo. на бумаге все прекрасно, но что делать когда в качестве ключей в программе не std::string, а сишные строки возвращаемые например функциями ОС? в этом случае map::find будет из сишной строки лепить временную std::string дергая malloc\free. В итоге на ровном месте получаем чудовищное падение производительности из-за того, что в stl не удосужились слепить шаблонный map::find употребляющий произвольный тип ключа.

Объясни , что тебе мешает сделать ассоциативный массив с ключом сишная строка ?

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

M>Объясни , что тебе мешает сделать ассоциативный массив с ключом сишная строка ?
Неудобно.
1) Надо писать специальный компоратор.
2) Надо как-то владеть ключами.

Но в целом можно конечно что-нибудь на эту тему соорудить, кто бы спорил. Другое дело, что хрен ли это в стандартной библиотеке не стали делать?

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

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

M>>Объясни , что тебе мешает сделать ассоциативный массив с ключом сишная строка ?
E>Неудобно.
E>1) Надо писать специальный компоратор.
E>2) Надо как-то владеть ключами.

E>Но в целом можно конечно что-нибудь на эту тему соорудить, кто бы спорил. Другое дело, что хрен ли это в стандартной библиотеке не стали делать?

Было бы супер неадекватно делать специализацию , которая со встроенными сишными строками вела себя уникальным образом.
Критикуешь — предлагай!

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

M>Было бы супер неадекватно делать специализацию , которая со встроенными сишными строками вела себя уникальным образом.
M>Критикуешь — предлагай!

Ну, одно из решений -- разрешить сравнивать ключ с любым типом, при помощи шаблонного метода...

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

Но тут есть ещё одна беда. Суть беды состоит в том, что дерево из 0-терминированных строк можно намного лучше упаковать. И можно бы было иметь какой-то map для таких случаев. Или, хотя бы иметь какую-то конструкцию, которую можно было бы позволить авторам реализации специализировать таким способом...

Но это я так, в порядке спонсорской помощи... Я-то свой выбор давно уже сделал

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

E>Но в целом можно конечно что-нибудь на эту тему соорудить, кто бы спорил. Другое дело, что хрен ли это в стандартной библиотеке не стали делать?
Для С-шных строк стоит использовать hash_map, а не tree.

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

M>Было бы супер неадекватно делать специализацию , которая со встроенными сишными строками вела себя уникальным образом.
M>Критикуешь — предлагай!

1) Писать надо в соотвествии с принципом KISS, без извращений и подросткового пафоса
2) Вместо шизы аллокатороров — нормальные интрузивные контейнеры для list/map/hash_map.
3) Методы работающие с ключем — шаблонные и хавают любой совместимый тип.

Это простые и очевидные вещи которые позволяют программировать без дополнительных костылей и извращений неизбежных в случае использования stl

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

C>Для С-шных строк стоит использовать hash_map, а не tree.

А если и tree, то тогда уж префиксное...

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

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

M>>Было бы супер неадекватно делать специализацию , которая со встроенными сишными строками вела себя уникальным образом.
M>>Критикуешь — предлагай!

K>1) Писать надо в соотвествии с принципом KISS, без извращений и подросткового пафоса
K>2) Вместо шизы аллокатороров — нормальные интрузивные контейнеры для list/map/hash_map.
K>3) Методы работающие с ключем — шаблонные и хавают любой совместимый тип.

K>Это простые и очевидные вещи которые позволяют программировать без дополнительных костылей и извращений неизбежных в случае использования stl

Вы наверное шутите ? Мы обсуждаем библиотеку для универсального использования а вы приводите конкретный пример и обижаетель "не работает". Вы сами можете написать сравнительный анализ использования интрузивных или неинтрузивных контейнеров для библиотеки "общего назначения" ?

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

K>>Это простые и очевидные вещи которые позволяют программировать без дополнительных костылей и извращений неизбежных в случае использования stl

M>Вы наверное шутите ? Мы обсуждаем библиотеку для универсального использования а вы приводите конкретный пример и обижаетель "не работает".

а вам этого мало? перечитайте веточку. stl — кривое поделие, источник костылей и воркэраундов в коде. Кроме того она банально неудобная и черезмерно многословная.

M>Вы сами можете написать сравнительный анализ использования интрузивных или неинтрузивных контейнеров для библиотеки "общего назначения" ?

Интрузивные контейнеры гораздо более универсальная вещь нежели stl-like (речь идет естственно о node-based контейнерах). Во первых на базе интрузивных контейнеров можно всегда и без всяких проблем слепить неинтрузивные. Во вторых интрузивный контейнер свободен от необходимости аллоцировать элементы, что дает огромное преимущество. Программист сам аллоцирует обьект как считает нужным и помещает его в контейнер. Например, обькты могут быть созданы статически и затем помещены в контейнер. В контейнерах stl-like такое не сделаешь никаким аллокатором, хотябы в силу того что они расчитаны на копируемые типы и помещение обьекта в контейнер требует аллокаци элемента.

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

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

K>>>Это простые и очевидные вещи которые позволяют программировать без дополнительных костылей и извращений неизбежных в случае использования stl

M>>Вы наверное шутите ? Мы обсуждаем библиотеку для универсального использования а вы приводите конкретный пример и обижаетель "не работает".

K>а вам этого мало? перечитайте веточку. stl — кривое поделие, источник костылей и воркэраундов в коде. Кроме того она банально неудобная и черезмерно многословная.
Читал, в основном безграмотность.

M>>Вы сами можете написать сравнительный анализ использования интрузивных или неинтрузивных контейнеров для библиотеки "общего назначения" ?

K>Интрузивные контейнеры гораздо более универсальная вещь нежели stl-like (речь идет естственно о node-based контейнерах). Во первых на базе интрузивных контейнеров можно всегда и без всяких проблем слепить неинтрузивные.
Вы представляете себе каждый раз оборачивать std::vector<int> в неинтрузивную обертку ? Может еще раз подумать зачем контейнеры "общего назначения" неинтрузивные?

K> Во вторых интрузивный контейнер свободен от необходимости аллоцировать элементы, что дает огромное преимущество. Программист сам аллоцирует обьект как считает нужным и помещает его в контейнер. Например, обькты могут быть созданы статически и затем помещены в контейнер. В контейнерах stl-like такое не сделаешь никаким аллокатором, хотябы в силу того что они расчитаны на копируемые типы и помещение обьекта в контейнер требует аллокаци элемента.

В общем случае это видимо ОЧЕНЬ удобно, отделить время жизни объекта входящего в контейнер от времени жизни контейнера.

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

K>... В контейнерах stl-like такое не сделаешь никаким аллокатором, хотябы в силу того что они расчитаны на копируемые типы и помещение обьекта в контейнер требует аллокаци элемента.

Можно поместить указатели, на статические данные, например...

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

M>>>Вы наверное шутите ? Мы обсуждаем библиотеку для универсального использования а вы приводите конкретный пример и обижаетель "не работает".

K>>а вам этого мало? перечитайте веточку. stl — кривое поделие, источник костылей и воркэраундов в коде. Кроме того она банально неудобная и черезмерно многословная.
M>Читал, в основном безграмотность.
да, а stl вся такая удобная и пушистая. смешно.

M>>>Вы сами можете написать сравнительный анализ использования интрузивных или неинтрузивных контейнеров для библиотеки "общего назначения" ?

K>>Интрузивные контейнеры гораздо более универсальная вещь нежели stl-like (речь идет естственно о node-based контейнерах). Во первых на базе интрузивных контейнеров можно всегда и без всяких проблем слепить неинтрузивные.
M>Вы представляете себе каждый раз оборачивать std::vector<int> в неинтрузивную обертку ? Может еще раз подумать зачем контейнеры "общего назначения" неинтрузивные?

ты чтоже читать не умеешь?
K>>речь идет естственно о node-based контейнерах

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

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

K>>... В контейнерах stl-like такое не сделаешь никаким аллокатором, хотябы в силу того что они расчитаны на копируемые типы и помещение обьекта в контейнер требует аллокаци элемента.

E>Можно поместить указатели, на статические данные, например...

можно, но указатели тоже нужно где-то хранить.

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

M>>Читал, в основном безграмотность.
K>да, а stl вся такая удобная и пушистая. смешно.
Не пушистая, а требует достаточно высокой квалификации.

K>ты чтоже читать не умеешь?
K>>>речь идет естственно о node-based контейнерах

Т.е. для node-based одно время жизни , для других другое ? Очень удобно ...

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

M>Не пушистая, а требует достаточно высокой квалификации.
IMHO, это недостаток...