| ||
STL/Boost нам строить и жить помагает
Спасибо, мы обходимся без него
Сами мы не местные
Тема: STL, Boost
STL, Boost
Вот, столкнулся на свою голову, решил спросить..
Помагает ли лично вам STL ? мне он жутко непонравился, изза несистемности, а у меня к этому болезное отношение.
и еще столкнулся что трудоемкость его изучения равна трудоемкости самостоятельной реализации требуемых алгоримов. Вижу, что народ пользуются, но читаемость образуемого кода граничит с безумием (пример- фри драйвер постгиса для автокада).
А Вы пробовали сами написать нечто вроде std::map? Да так, чтоб работало быстро?
А можно конкретные примеры "несистемности" stl?
Лично я "за" использование stl/boost, так как, во-первых, эти библиотеки отлажены в отличие от самописных, во-вторых, во многих фирмах являются стандартом де-факто, а кое-где и де-юро.
Что касается boost-а, эта библиотека написана на порядок грамотнее, чем stl.
PS: Кривой код можно написать на чем угодно.
STL реализации различных контейнеров как раз далеко не самые быстрые.Сообщение от leviaphan
Их достоинство в унификации, а не в скорости.
Использование STL и boost (контейнеры+smart указатели) дает возможность в прикладном коде полностью отказаться от указателей, что на порядки повышает надежность и скорость производства программ.
Поэтому Boost и STL - обязательны к применению.
Да, но их и нельзя назвать медленными. По крайней мере алгоритмы, которые в них используются, эффективны.
Я же говорю, скорость для меня на втором месте после надежности.
Но если уж говорить про эффективность, то могу привести такой пример.
Я для одного проекта исследовал производительность трех контейнеров, реализующих интерфейс map в VS2008.
- std::map
- stdext::hash_map
- портированный мной в С++ Java HashMap
Так вот какие результаты:
Т.е. видно, что stdext::hash_map в 2-3 раза хуже чем портированный из Java.Код: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
А зачем там exeptions.. это же лишнее сохранение состояний..
я привык по старинке.. верни нулл и свободен..
Было бы интересно взглянуть на код бенчмарка..
PS: Функцию хеширования для строки брали из stl, или тоже портировали?
Очередной динозаврСейчас ты спрашиваешь зачем исключения и 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). И при этом у тебя будет выбор, которого полностью лишены С++ пуристы.
Ты сможешь выбрать именно то, что тебе надо, а не то что дают.
Минус - тебя перестанут понимать другие программисты, молодежь откажется поддерживать непонятный код, и т.п. и т.д.
Реашй сам, что важнее для тебя.
The future is already here - it is just unevenly distributed. (c) W. Gibson
Хеш-функция насколько я помню использовалась из STL.
Код теста приводить нет смысла - там циклы и замеры времени.
Это правда. Но не вся. В мейнстриме важно писать код который легко поддерживать (дополнять, исправлять), не достаточно чтобы твой код был понятен.
Если вы не умеете писать "читаемый, понимаемый и пр" и одновременно "эффективный" код то не надо экстраполировать это на всех.Если ты программист на С++ и пишешь в первую очередь эффективный код (а читаемый, понимаемый, объектно-ориентированный и пр и пр. - во вторую) - то STL лучше забыть (как и многие другие фичи С++).
Не надо путать способность написать и необходимость этого.Btw программист не способный написать собственную реализацию хеша или списка вызывает у меня иронию и жалость.
Для прочих людей Boost - свалка изобретенных велосипедов на 90%.Т.е. вы предлагаете заменить одну свалку на другую.50% либ на sf.net убьют STL+Boost одной левой (это если тебе не хватает хеша из glibc).
Не надо путать сложность разработки Boost и сложность его использования.Рабочий код - это в первую очередь простой код. А код сохраняющий свою работоспособность >10 лет - это очень простой код. Imho Boost простым не назовет никто.
Похоже на религиозную проповедь. Не хватает только явного упоминания рая и ада.И при этом у тебя будет выбор, которого полностью лишены С++ пуристы.
Ты сможешь выбрать именно то, что тебе надо, а не то что дают.
Программисты делятся на два вида: те кто понимает преимуществ исключений и умеет их использовать, и тех кто еще не понял и исключения у них как все непонятное вызывают отторжение.
Если кратко то разница между исключениями и кодами возврата в том что исключения не обязательно обрабатывать в том месте где они возникли.
Это приципиальный момент, имеющий очень существенные последствия для написания высоконадежных программ (под надежностью я имею в виду % кода который протестирован или пройден отладчиком и там гарантированно нет багов).
Например, чтобы протестировать код:Требуется создать четыре варианта тестов (2^2).Код:if (do1() == ERROR) return ERROR; if (do2() == ERROR) return ERROR;
Если же взять реальное приложение, то там этих условий множество. И понятно что никто не будет тестировать все 2^много вариантов.
Теперь если взять код с исключениями.
Строго один вариант. И его есть возможность протестировать, а значит и гарантировать надежность этого участка кода.Код:do1(); do2();
Да, у исключений есть недостатки - генерация исключения и последующий его перехват очень затратная операция - десятки а то и сотни тысяч тактов процессора (в зависимости от реализации).
Однако вызов исключения достаточно редкая операция (по крайней мере так нужно проектировать приложение), поэтому эта целая миллисекунда на вызов исключения никакой роли в производительности не играет.
Второй момент, это несовместимость исключений с кодом который написан без учета исключений. Приходится писать дополнительный слой оберток. Это же ужас-ужас
Так и знал, что ты выползешь
Теперь понятно почему он std::map хешем называетТак и знал, что ты выползешь
ага ) точно что динозавр... с 1984 г ..Очередной динозавр
спрашиваю, т.к. мне положить на то как я привык, мне надо как правильно теперь.... но получается что ( время личного изучения боост/стл + пригибание ее на то что нужно именно тебе ) >>= (времени на реализацию нужной функциональности (с должной эффекивностью)).
Вставлю свои 5 коп. Знание STL для любого С++ программиста обязательно. Boost - очень круто конечно, но редко где используется. А то что код где используются сишные масивы удобней и проще - полный чес
шас нечнется флейм.
я не знаю где кто работает - я работаю сейчас на авионику. и именно железнячка, как ты говоришь.
эффективность кода - это мало кого интерисует. в первую очередь ПОНИМАЕМ, ЛЕГКО ЧИТАЕМ - вот что главное..
так как я сегодня работаю а завтра нет, придет другой и должен быстренько продолжить.
и здесь STL самое то.
я не знаю НИ ОДНОГО проекта НИ ОДНОЙ фирмы где бы были критерии. писать в первую очередь эффективно, а уз потом читаемо.
список фирм где я поработал приводить не буду... не к чему но поверь там первые величины.
индивидуальная субстанция разумной природы
Да я вобчем-то только ответил на вопрос топикстартера, которого к слову лично знаю.
Флеймить как обычно времени нет.
Но раз уж ты настаиваешь...
В авионике все проще - если система зависнет, то значит не упадет.
Хотя чисто для интереса, опыт программистов NASA и космической Европы впечатляет - место в 10 крупнейших багов XX века плюс космические катастрофы PowerPoint культуры заслуживают весьма внимательного изучения.
ППКС
Ключевое слово - для тех проектов где ты представляешь ровно ту ценность которую можно заменить в течение суток без потерь. Т.е. конвейер, RAD, массовое производство.
Очевидно что есть и другие проекты, где важным является другое.
Например при попытке заменить Торвальдса на своем месте - что-то изменится, не правда ли?
Обслуживанием youtube занимается всего 5 человек.
Попробуй заменить половину из них. Я посмотрю что получится.
Посмотри на проекты, где руководителем является хозяин бизнеса.
Кого ты там заменишь?
Посмотри на малобюджетные проекты.
Посмотри на сам Google в момент его создания и подумай как можно было бы написать BigTable или MapReduce на тогдашнем STL.
Или кого там можно было бы заменить.
Ты говоришь не о программировании, ты говоришь о модели менеджмента.
Одной из многих.
Для этой конкретной модели в сочетании с конкретным языком программирования - ты прав.
Для остальных - нет.
Т.е. ты никогда не интересовался сколько стоит вывести гигабайт RAM на орбиту на спутнике? И как эта сумма соотносится с зарплатой программиста?
Я кстати могу тебе даже объяснить на примере, почему ты не знаешь таких фирм.
Для супер-пупер высокопроизводительных расчетов ты можешь арендовать BlueGene.
А можешь купить 120 Sony PlayStations и получить ровно ту же мощность в собственность при меньших затратах на обслуживание.
Ибо IBM саппорт стоит дороже двадцати студентов, знающих линукс.
Просто посчитай разницу в TCO - это далеко не лимон баксов.
А потом сообрази, что ты никогда не будешь работать в фирмах, которые строят такие кластера. Потому что ты мыслишь правильно и пишешь правильно, как в книжках написано. А в книжках про кластера из PS не написано -только в мейлистах универовских нищебродов, которые ты не читаешь.
А когда будет написано в книжках и это станет очередной крутой модой - идти туда уже будет поздно.
Т.е. прими как данность - ты видишь свой кусок бизнеса.
И твои правила верны для того куска бизнеса, который ты видишь.
И аргументы твои не из области программирования, а из области стратегии менеджмента.
Обычно в таких случаях закатывают глаза и говорят с придыханием - " там Такииие Люди работают!"
Для полноты впечатления.
А теперь встречные вопросы.
Расскажи как железячники программируют FPGA с помощью STL/Boost.
Или чем может помочь STL/Boost в мультиагентной системе (крутые железячники и авионика - ты ведь должен знать что это такое).
Кстати заодно расскажи как там помогают хваленые паттерны программирования.
Хотя бы укажи где в этой области STL или Boost могут хоть чем-то помочь.
Замечание о крутости фирм как ты сам понимаешь в зачет не идет, извини, одна очень крутая фирма благополучно шаттл грохнула, как я помню.
Btw, я сейчас работаю в HPC области.
Расскажи как на STL/Boost реализовать тупейший hyperquicksort двадцатилетней давности, не говоря об чем-то более новом.
А то может я что-то пропустил за то время, с тех пор пока ушел с PM плюсовых проектов...
The future is already here - it is just unevenly distributed. (c) W. Gibson
Начиная с 2к стандарта ВХДЛ начали появляться всякие плюшки с объектно-ориентированностью. Не впечатлило.
Хотя может просто не встречался ещё с задачами, где без них никуда.
Последний раз редактировалось Гай Монтего; 10.01.2010 в 11:55.
A book? Burn it!
Ваши права
Ответить с цитированием
Социальные закладки