STL, Boost

Вот, столкнулся на свою голову, решил спросить..
Помагает ли лично вам STL ? мне он жутко непонравился, изза несистемности, а у меня к этому болезное отношение.
и еще столкнулся что трудоемкость его изучения равна трудоемкости самостоятельной реализации требуемых алгоримов. Вижу, что народ пользуются, но читаемость образуемого кода граничит с безумием (пример- фри драйвер постгиса для автокада).

А Вы пробовали сами написать нечто вроде std::map? Да так, чтоб работало быстро?

А можно конкретные примеры "несистемности" stl?
Лично я "за" использование stl/boost, так как, во-первых, эти библиотеки отлажены в отличие от самописных, во-вторых, во многих фирмах являются стандартом де-факто, а кое-где и де-юро.
Что касается boost-а, эта библиотека написана на порядок грамотнее, чем stl.

PS: Кривой код можно написать на чем угодно.

[QUOTE=leviaphan;8959446]А Вы пробовали сами написать нечто вроде std::map? Да так, чтоб работало быстро?[/QUOTE]
STL реализации различных контейнеров как раз далеко не самые быстрые.
Их достоинство в унификации, а не в скорости.

Использование STL и boost (контейнеры+smart указатели) дает возможность в прикладном коде полностью отказаться от указателей, что на порядки повышает надежность и скорость производства программ.

Поэтому Boost и STL - обязательны к применению.

[QUOTE=18-я весна;9064049]STL реализации различных контейнеров как раз далеко не самые быстрые.
Их достоинство в унификации, а не в скорости.

Использование STL и boost (контейнеры+smart указатели) дает возможность в прикладном коде полностью отказаться от указателей, что на порядки повышает надежность и скорость производства программ.

Поэтому Boost и STL - обязательны к применению.[/QUOTE]

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

[QUOTE=leviaphan;9075079]Да, но их и нельзя назвать медленными. По крайней мере алгоритмы, которые в них используются, эффективны.[/QUOTE]
Я же говорю, скорость для меня на втором месте после надежности.
Но если уж говорить про эффективность, то могу привести такой пример.
Я для одного проекта исследовал производительность трех контейнеров, реализующих интерфейс map в VS2008.
- std::map
- stdext::hash_map
- портированный мной в С++ Java HashMap
Так вот какие результаты:
[CODE] 1) Algorithm/container comparison results for random strings
(avg. CPU time per item; 1-10000 items):
FILL SEARCH/FOUND SEARCH/NOT FOUND
STL hash_map 2965 852 306
STL map 3462 1572 842
Java HashMap (C++) 1581 451 101
[/CODE]

Т.е. видно, что stdext::hash_map в 2-3 раза хуже чем портированный из Java.

А зачем там exeptions.. это же лишнее сохранение состояний..
я привык по старинке.. верни нулл и свободен..

[QUOTE=18-я весна;9082996]Я же говорю, скорость для меня на втором месте после надежности.
Но если уж говорить про эффективность, то могу привести такой пример.
Я для одного проекта исследовал производительность трех контейнеров, реализующих интерфейс map в VS2008.
- std::map
- stdext::hash_map
- портированный мной в С++ Java HashMap
Так вот какие результаты:
[CODE] 1) Algorithm/container comparison results for random strings
(avg. CPU time per item; 1-10000 items):
FILL SEARCH/FOUND SEARCH/NOT FOUND
STL hash_map 2965 852 306
STL map 3462 1572 842
Java HashMap (C++) 1581 451 101
[/CODE]

Т.е. видно, что stdext::hash_map в 2-3 раза хуже чем портированный из Java.[/QUOTE]

Было бы интересно взглянуть на код бенчмарка..
PS: Функцию хеширования для строки брали из stl, или тоже портировали?

[QUOTE=sid@merlin;9085260]
А зачем там exeptions.. это же лишнее сохранение состояний..
я привык по старинке.. верни нулл и свободен..
[/QUOTE]
Очередной динозавр :) Сейчас ты спрашиваешь зачем исключения и STL, еще через лет 10 спросишь зачем auto и лямбды, а вот меня интересует зачем вообще что-то спрашивать если ты просто привык писать по старинке и это имеет определяющее значение? Вокруг полно книг как правильно писать на С++, даже Страуструп советует вовсю юзать контейнеры, хотя когда-то он упирался против введения виртуальных функций из-за оверхеда. Никто тебя не переубедит пока ты не подтянешь знание языка до приемлемого уровня...

Мне триста лет, я выполз из тьмы... (c)

STL обязателен к применению, если ты:
мейнстрим программист на С++
работаешь в коллективе мейнстрим программистов на С++
хочешь хорошо понимать других мейнстрим программистов на С++
хочешь чтобы твой код хорошо понимали другие мейнстрим программисты на С++

Если ты программист на С++ и пишешь в первую очередь эффективный код (а читаемый, понимаемый, объектно-ориентированный и пр и пр. - во вторую) - то STL лучше забыть (как и многие другие фичи С++).
Железячников, работающих с STL мне даже вспомнить трудно.
Если ты программист на С++ и тебе нравится унифицированность, удобство и простота и отсутсвие ошибок, уход от арифметики пойтеров, унифицированные интерфейсы и т.п. - STL для тебя конечно, но подумай, может стоить перейти на Java - там все это есть и лучше качеством и безглючней. :-)

Btw программист не способный написать собственную реализацию хеша или списка вызывает у меня иронию и жалость.

Boost отдельная песня. Для программистов, считающих С++ всем окружающим миром - самое то. Вылазить наружу из своей скорлупы можно как можно реже или вообще не вылазить. :-)
Для прочих людей Boost - свалка изобретенных велосипедов на 90%.
Желающие могут сами попробовать оценить его полезность - прикинуть на глаз отношение новой функциональности к общему количеству кода.
Известная детская болезнь молодого С++ программиста - написать свой класс Tmatrix. Boost - это всемирный заговор таких программистов :-)
Пример - есть куча межязыковых стандартов. Которые имеют общую структуру для всех языков. MPI, BlAS и многие другие.
Человек который их знает - может работать с любым языком и с любой имплементацией, даже неполной или специфичной.
Человек который знает Boost-оболочки - может работать только с Boost-оболочками.

Соответственно здесь мы видим классическую ловушку - программисту предложили +1 к удобству и -2 к функциональности. И программисты повелись, как они часто ведутся на такое. В последовательности таких предложений мы видим то что имеем - программиста который умеет все но в очень узких рамках и только если у него установлен любимый IDE. И впадает в ступор при попытке решить задачу выходящую за его рамки. :-(

sid@merlin, если тебе нужна эффективность и долгое время работы проекта - забей на эти свистелки. Это хорошая тема в курилке - обсуждение новых фич в Boost'e или хешмэп в STL :-) Когда нет времени на перекур - начинаешь пониматть какой это реально дрек.
Рабочий код - это в первую очередь простой код. А код сохраняющий свою работоспособность >10 лет - это очень простой код. Imho Boost простым не назовет никто.
50% либ на sf.net убьют STL+Boost одной левой (это если тебе не хватает хеша из glibc). И при этом у тебя будет выбор, которого полностью лишены С++ пуристы.
Ты сможешь выбрать именно то, что тебе надо, а не то что дают.

Минус - тебя перестанут понимать другие программисты, молодежь откажется поддерживать непонятный код, и т.п. и т.д.
Реашй сам, что важнее для тебя.

[QUOTE=BloodAxe;9088312]Было бы интересно взглянуть на код бенчмарка..
PS: Функцию хеширования для строки брали из stl, или тоже портировали?[/QUOTE]
Хеш-функция насколько я помню использовалась из STL.
Код теста приводить нет смысла - там циклы и замеры времени.

[QUOTE=homo ludens;9093671]STL обязателен к применению, если ты:
мейнстрим программист на С++
работаешь в коллективе мейнстрим программистов на С++
хочешь хорошо понимать других мейнстрим программистов на С++
хочешь чтобы твой код хорошо понимали другие мейнстрим программисты на С++
[/QUOTE]
Это правда. Но не вся. В мейнстриме важно писать код который легко поддерживать (дополнять, исправлять), не достаточно чтобы твой код был понятен.

[QUOTE]Если ты программист на С++ и пишешь в первую очередь эффективный код (а читаемый, понимаемый, объектно-ориентированный и пр и пр. - во вторую) - то STL лучше забыть (как и многие другие фичи С++).
[/QUOTE]
Если вы не умеете писать "читаемый, понимаемый и пр" и одновременно "эффективный" код то не надо экстраполировать это на всех.

[QUOTE]Btw программист не способный написать собственную реализацию хеша или списка вызывает у меня иронию и жалость.[/QUOTE]
Не надо путать способность написать и необходимость этого.

[QUOTE]Для прочих людей Boost - свалка изобретенных велосипедов на 90%.[/QUOTE]
[QUOTE]50% либ на sf.net убьют STL+Boost одной левой (это если тебе не хватает хеша из glibc).
[/QUOTE]
Т.е. вы предлагаете заменить одну свалку на другую. :)

[QUOTE]Рабочий код - это в первую очередь простой код. А код сохраняющий свою работоспособность >10 лет - это очень простой код. Imho Boost простым не назовет никто.[/QUOTE]
Не надо путать сложность разработки Boost и сложность его использования.

[QUOTE]
И при этом у тебя будет выбор, которого полностью лишены С++ пуристы.
Ты сможешь выбрать именно то, что тебе надо, а не то что дают.
[/QUOTE]
Похоже на религиозную проповедь. Не хватает только явного упоминания рая и ада.

[QUOTE=sid@merlin;9085260]А зачем там exeptions.. это же лишнее сохранение состояний..
я привык по старинке.. верни нулл и свободен..[/QUOTE]

Программисты делятся на два вида: те кто понимает преимуществ исключений и умеет их использовать, и тех кто еще не понял и исключения у них как все непонятное вызывают отторжение.

Если кратко то разница между исключениями и кодами возврата в том что исключения не обязательно обрабатывать в том месте где они возникли.

Это приципиальный момент, имеющий очень существенные последствия для написания высоконадежных программ (под надежностью я имею в виду % кода который протестирован или пройден отладчиком и там гарантированно нет багов).
Например, чтобы протестировать код:[CODE]if (do1() == ERROR) return ERROR;
if (do2() == ERROR) return ERROR;
[/CODE]
Требуется создать четыре варианта тестов (2^2).
Если же взять реальное приложение, то там этих условий множество. И понятно что никто не будет тестировать все 2^много вариантов.
Теперь если взять код с исключениями.
[CODE]do1();
do2();
[/CODE]
Строго один вариант. И его есть возможность протестировать, а значит и гарантировать надежность этого участка кода.

Да, у исключений есть недостатки - генерация исключения и последующий его перехват очень затратная операция - десятки а то и сотни тысяч тактов процессора (в зависимости от реализации).
Однако вызов исключения достаточно редкая операция (по крайней мере так нужно проектировать приложение), поэтому эта целая миллисекунда на вызов исключения никакой роли в производительности не играет.
Второй момент, это несовместимость исключений с кодом который написан без учета исключений. Приходится писать дополнительный слой оберток. Это же ужас-ужас :)

[QUOTE=homo ludens;9093671]
Мне триста лет, я выполз из тьмы... (c)
[/quote]
Так и знал, что ты выползешь :) Дело в том, что если человек заявляет о превосходстве С над С++, то его рассуждения о ущербности STL уже никого не удивляют...

[QUOTE=Reflector;9097394]Так и знал, что ты выползешь :) Дело в том, что если человек заявляет о превосходстве С над С++, то его рассуждения о ущербности STL уже никого не удивляют...[/QUOTE]
Теперь понятно почему он std::map хешем называет :)

[QUOTE=Reflector;9088538]Очередной динозавр :) Сейчас ты спрашиваешь зачем исключения и STL, еще через лет 10 спросишь зачем auto и лямбды, а вот меня интересует зачем вообще что-то спрашивать если ты просто привык писать по старинке и это имеет определяющее значение? Вокруг полно книг как правильно писать на С++, даже Страуструп советует вовсю юзать контейнеры, хотя когда-то он упирался против введения виртуальных функций из-за оверхеда. Никто тебя не переубедит пока ты не подтянешь знание языка до приемлемого уровня...[/QUOTE]

ага ) точно что динозавр... с 1984 г ..
спрашиваю, т.к. мне положить на то как я привык, мне надо как правильно теперь.... но получается что ( время личного изучения боост/стл + пригибание ее на то что нужно именно тебе ) >>= (времени на реализацию нужной функциональности (с должной эффекивностью)).

Вставлю свои 5 коп. Знание STL для любого С++ программиста обязательно. Boost - очень круто конечно, но редко где используется. А то что код где используются сишные масивы удобней и проще - полный чес :) Хотя конечно железячникам без них никуда...

[QUOTE=homo ludens;9093671]....
Если ты программист на С++ и пишешь в первую очередь эффективный код (а читаемый, понимаемый, объектно-ориентированный и пр и пр. - во вторую) - то STL лучше забыть (как и многие другие фичи С++).
Железячников, работающих с STL мне даже вспомнить трудно.
....[/QUOTE]

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

эффективность кода - это мало кого интерисует. в первую очередь ПОНИМАЕМ, ЛЕГКО ЧИТАЕМ - вот что главное..
так как я сегодня работаю а завтра нет, придет другой и должен быстренько продолжить.
и здесь STL самое то.

я не знаю НИ ОДНОГО проекта НИ ОДНОЙ фирмы где бы были критерии. писать в первую очередь эффективно, а уз потом читаемо.

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

[QUOTE=Ull9;9128033]шас нечнется флейм.
[/quote]
Да я вобчем-то только ответил на вопрос топикстартера, которого к слову лично знаю.
Флеймить как обычно времени нет.
Но раз уж ты настаиваешь... :-)

[QUOTE=Ull9;9128033]
я не знаю где кто работает - я работаю сейчас на авионику. и именно железнячка, как ты говоришь.
[/quote]
В авионике все проще - если система зависнет, то значит не упадет. :-)
Хотя чисто для интереса, опыт программистов NASA и космической Европы впечатляет - место в 10 крупнейших багов XX века плюс космические катастрофы PowerPoint культуры заслуживают весьма внимательного изучения.

[QUOTE=Ull9;9128033]
эффективность кода - это мало кого интерисует. в первую очередь ПОНИМАЕМ, ЛЕГКО ЧИТАЕМ - вот что главное..
так как я сегодня работаю а завтра нет, придет другой и должен быстренько продолжить.
и здесь STL самое то.
[/quote]

ППКС
Ключевое слово - для тех проектов где ты представляешь ровно ту ценность которую можно заменить в течение суток без потерь. Т.е. конвейер, RAD, массовое производство.
Очевидно что есть и другие проекты, где важным является другое.
Например при попытке заменить Торвальдса на своем месте - что-то изменится, не правда ли?
Обслуживанием youtube занимается всего 5 человек.
Попробуй заменить половину из них. Я посмотрю что получится.
Посмотри на проекты, где руководителем является хозяин бизнеса.
Кого ты там заменишь?
Посмотри на малобюджетные проекты.
Посмотри на сам Google в момент его создания и подумай как можно было бы написать BigTable или MapReduce на тогдашнем STL.
Или кого там можно было бы заменить.
Ты говоришь не о программировании, ты говоришь о модели менеджмента.
Одной из многих.
Для этой конкретной модели в сочетании с конкретным языком программирования - ты прав.
Для остальных - нет.

[QUOTE=Ull9;9128033]
я не знаю НИ ОДНОГО проекта НИ ОДНОЙ фирмы где бы были критерии. писать в первую очередь эффективно, а уз потом читаемо.
[/quote]

Т.е. ты никогда не интересовался сколько стоит вывести гигабайт RAM на орбиту на спутнике? И как эта сумма соотносится с зарплатой программиста?

Я кстати могу тебе даже объяснить на примере, почему ты не знаешь таких фирм.

Для супер-пупер высокопроизводительных расчетов ты можешь арендовать BlueGene.
А можешь купить 120 Sony PlayStations и получить ровно ту же мощность в собственность при меньших затратах на обслуживание.
Ибо IBM саппорт стоит дороже двадцати студентов, знающих линукс.
Просто посчитай разницу в TCO - это далеко не лимон баксов.
А потом сообрази, что ты никогда не будешь работать в фирмах, которые строят такие кластера. Потому что ты мыслишь правильно и пишешь правильно, как в книжках написано. А в книжках про кластера из PS не написано -только в мейлистах универовских нищебродов, которые ты не читаешь.
А когда будет написано в книжках и это станет очередной крутой модой - идти туда уже будет поздно.
Т.е. прими как данность - ты видишь свой кусок бизнеса.
И твои правила верны для того куска бизнеса, который ты видишь.
И аргументы твои не из области программирования, а из области стратегии менеджмента.

[QUOTE=Ull9;9128033]
список фирм где я поработал приводить не буду... не к чему но поверь там первые величины.[/QUOTE]

Обычно в таких случаях закатывают глаза и говорят с придыханием - " там Такииие Люди работают!" :-)
Для полноты впечатления.

А теперь встречные вопросы.

Расскажи как железячники программируют FPGA с помощью STL/Boost. :-)
Или чем может помочь STL/Boost в мультиагентной системе (крутые железячники и авионика - ты ведь должен знать что это такое).
Кстати заодно расскажи как там помогают хваленые паттерны программирования. :-)
Хотя бы укажи где в этой области STL или Boost могут хоть чем-то помочь.
Замечание о крутости фирм как ты сам понимаешь в зачет не идет, извини, одна очень крутая фирма благополучно шаттл грохнула, как я помню.

Btw, я сейчас работаю в HPC области.
Расскажи как на STL/Boost реализовать тупейший hyperquicksort двадцатилетней давности, не говоря об чем-то более новом.
А то может я что-то пропустил за то время, с тех пор пока ушел с PM плюсовых проектов... :-)

Начиная с 2к стандарта ВХДЛ начали появляться всякие плюшки с объектно-ориентированностью. Не впечатлило.

Хотя может просто не встречался ещё с задачами, где без них никуда.