STL, Boost

[Reflector]

а С полезен при программировании ПЛИС?

Конечно. Если я правильно понял, то С программисты работаю быстрее, меньше впадают в ступор, у них меньше багов, а в то время как С++ программисты в курилке обсуждают Boost, у них нет на это времени, т.к. они еще и постоянно заняты самосовершенствованием. Вообще если каждый день вместо зарядки писать небольшую программку на чистом С, то проживешь 120 лет и это может быть полезно даже для изучения китайского языка

ps. С плисками дело не имел, на МК писал довольно много, сначала на асме, потом на С. То же самое с шейдерами, сначала был асм, потом HLSL, теперь только HLSL, т.к. асм уже убрали. Еще раньше, на Спектруме, все в тактах высчитывали... Только какое отношение к этому имеет использованию STL или Boost? Естественно я их использую когда пишу на С++(Boost по минимуму), так же как использую огромные стандартные библиотеки когда пишу на C#... А тут же полный бред получается: Boost - это детская болезнь и всемирный заговор молодых С++ программистов, пишущих свои классы, а в среде Сишников постоянная самостоятельная реализация по сути того же - это признак зрелости Косвенно этот факт подтверждается тем, что когда какой-нить чел из комитета по стандартизации С++ предлагает свою библиотеку в Boost, другие спецы ковыряются в исходниках и должны их одобрить, а зрелым С программистам это нафиг не нужно, они пишут сразу в чистовик

[homo ludens]

вы оба правы/неправы. все зависит от конкретных случаев.
да и стл уместен там где уместен, не более того.

ППКС

по поводу гениев, слушал я выступление галвного архитектора ебая, так вот. его принцип
если кто то стал незаменимым - его следует немедленно увольнять.

Дык это известный принцип менеджмента.
В фирме должен быть только один незаменимый человек - ее хозяин. А его не уволишь.
Другой вопрос, что один из архитекторов ебая как-то заявлял, что их переход на джаву вызван невозможностью компилятора С++ обработать требуемое количество методов одного класса.

в F-35 15 млн строк кода. надо было бы больше написали бы больше. память практически не ограничена.

А какого черта тогда на джаве не пишут?
Скорость разработки по любому будет выше.

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

Блин, третья команда - результат один. Все ленивые?

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

Смотря как писать и как проектировать, хотя рефакторинг что в С что в С++, по сравнению с джавой не радуют. И рефакторинг в С таки да хуже чем в С++.

Да, и STL кстати никакого отношения к ООП не имеет, поскольку является всего лишь библиотекой алгоритмов.

В отличие от многих других библиотек алгоритмов STL замкнут относительно языка.
Ты не можешь использовать его нигде кроме как в С++.
В отличие от большинства других реализаций.
Это провоцирует на написание кода на С++ там, где С++ нафиг не нужен, видел тут китайца, который одну строчку на баше в пять страниц кода на С++ превратил.
С инкапсуляцией и даже с exceptions.
Что характерно, падала на неправильно сформированных данных. В отличие от.

а кстати, вот у меня вопрос к С-спецам.
как написать на чистом С RAII паттерн?

У меня ответ - а нафига это надо на языке без исключений и без деструкторов автоматических переменных?
longjump фильтровать?
Ты еще на SQL "Паттерн Недопускающий Некоммита Транзакции" реализовать попробуй.
Я тебе сейчас могу навскидку предложить методы окончательного решения неправильного распределения ресурсов. На С. Которые не дадут программисту никак написать неправильный код независимо от того, "правильно" он пишет или "неправильно".
Только это оверкилл нафиг не нужный никому, который займет больше ресурсов человека, чем освободит.

Счас вам тут напишут, то хороший С-стайл программист гораздо круче компилятора справляется с контролем за освобождением выделенных ресурсов, поэтому у него никогда не бывает утечек памяти

Хороший С-стайл программист (как и С++-стайл) не заморачивается такими вопросами и использует например http://valgrind.org вместе с тестером.
И писать паттерны и оболочки для защиты от утечек памяти - это по моему полный финиш.
Лучше уж сборщик мусора прикрутить. Или на джаву переходить.
У меня лимит утечек в продакшн коде - две в год. Со сроком ловли - одна неделя.
Последние лет 10 еще не превышал.

а С полезен при программировании ПЛИС?

Я никогда не утверждал, что С умеет все.
Мои оппоненты утверждают, что С++ круче всех и умеет все.
А я считаю, что каждую задачу решают тем языком, который лучше для этого подходит. Соответственно глупо использовать С++ вместо Verilog.

Косвенно этот факт подтверждается тем, что когда какой-нить чел из комитета по стандартизации С++ предлагает свою библиотеку в Boost, другие спецы ковыряются в исходниках и должны их одобрить, а зрелым С программистам это нафиг не нужно, они пишут сразу в чистовик

Когда я первый раз на этом форуме заявил, что С++ не имеет собственной ниши и уйдет, в мире было на некоторое количество С++ вакансий больше. И на некоторое количество С и Java-вакансий - меньше.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Если вам нужна эффективность - почему не С?
Если нужен комфорт - почему не Java?
А если кто-то не умеет просчитать внутренние конфликты системы и спрогнозировать ее развитие - то почему он программист?

[18-я весна]

Блин, третья команда - результат один. Все ленивые?

Править в консерватории.

Смотря как писать и как проектировать, хотя рефакторинг что в С что в С++, по сравнению с джавой не радуют. И рефакторинг в С таки да хуже чем в С++.

Вы путаете С++ vs C и OOП vs Non-OOП.
ООП можно реализовать и в С и в С++ и вообще в любом языке.

Хороший С-стайл программист (как и С++-стайл) не заморачивается такими вопросами и использует например http://valgrind.org вместе с тестером.

Если использования третьих софтов это "не заморачивается" то я балерина.

И писать паттерны и оболочки для защиты от утечек памяти - это по моему полный финиш.

RAII и другие паттерны в С++ предназначены не для того чтобы бороться с утечками и исключениями. А для того чтобы писать прикладной код не отвлекаясь на низкоуровневые вставки. Это реализация одного из основных принципов ООП - инкапсуляции.

Если вам нужна эффективность - почему не С?
Если нужен комфорт - почему не Java?

Потому что ни то ни другое не является истиной. На С++ вполне можно писать столь же эффективные реализации как и в С (при одинаковой надежности). Там где С обгоняет С++ там всегда ниже надежность.
Насчет комфорта Java - это тоже очень субъективно. А в плане утечек ресурсов (не памяти) - там есть вполне объективные проблемы.

[homo ludens]

Вы путаете С++ vs C и OOП vs Non-OOП.
ООП можно реализовать и в С и в С++ и вообще в любом языке.

Да, и на SQL?
C OQL имеете опыт работы? Сочуствую...

Если использования третьих софтов это "не заморачивается" то я балерина.

С помощью этого софта проблема утечки памяти решена раз и навсегда.
И больше никогда не будет решаться мною.
Тебе если интересно корежить каждый день свой код под отсутствие утечек - вперед.
Главное - не заморачиваться.

RAII и другие паттерны в С++ предназначены не для того чтобы бороться с утечками и исключениями. А для того чтобы писать прикладной код не отвлекаясь на низкоуровневые вставки. Это реализация одного из основных принципов ООП - инкапсуляции.

Ясно.
Оказывается инкапсуляция нужна чтобы писать прикладной код не отвлекаясь на низкоуровневые вставки.
Сильный ход.
Я промолчу, ок?

Там где С обгоняет С++ там всегда ниже надежность.

Да,да конечно.
Как здесь:
http://web.archive.org/web/20060615055607/http://blogs.zdnet.com/threatchaos/?p=311
Ты как нибудь заморочься лишний раз, воспользуйся чужой тулзой codeviz и сравни C и C++ проекты с одинаковой функциональностей.
Очень поучительное зрелище.
И незабываемое.

Насчет комфорта Java - это тоже очень субъективно. А в плане утечек ресурсов (не памяти) - там есть вполне объективные проблемы.

Основные проблемы там по прежнему с производительностью.
Real-time Java конечно неизбежна как крах империализма.
Но примерно так же далеко...

На С++ вполне можно писать столь же эффективные реализации как и в С (при одинаковой надежности).

Воспользовавшись им как С.
Напишешь квин-программу под С++ где были бы полезны ООП плюшки и STL?
С той же эффективностью?

[Ull9]

у-у-у тут дискуссия раростается на 150 отдельных тредов

.....
Это провоцирует на написание кода на С++ там, где С++ нафиг не нужен, видел тут китайца, который одну строчку на баше в пять страниц кода на С++ превратил.
С инкапсуляцией и даже с exceptions.

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

1- язык с имеет дело с ресурсами, памятью хандлами файлов мутексами.
Очень важно их освобождать. и сборщик мусора туит не поможет. потому что освобождать их нужно в детерминированный момент времени ане когда нибудь.
пример в тему мютекс надо освобождать ровно тогда когда он не нужен, а не когда нибудь потом.
ПОСИКС еще никто как стандарт не отмненял. как это сделать на С? а через жопу

2. никто не говорит что С++ универсален и годен на все случаи жизни - не выдумывай. дурак китаец который вместо строчки баш скрипта написал несколько страниц на С++, похож на дурака менеджера который заставляет писать ОО код на чистом С.

[18-я весна]

Тебе если интересно корежить каждый день свой код под отсутствие утечек - вперед.

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

Оказывается инкапсуляция нужна чтобы писать прикладной код не отвлекаясь на низкоуровневые вставки.

Нет конечно, это вы сейчас домыслили успешно.
Инкапсуляция это сокрытие реализации, в том числе реализации кода низкого уровня от прикладного кода его использующего, но она не исчерпывается этим. В более широком смысле инкапсуляция это разбиение системы на компоненты взаимодействующие через API.
Чем проще АПИ, чем меньше от программиста требуется обязательных действий не связанных с прикладной задачей, тем надежнее итоговый софт, тем проще осуществлять рефакторинг и развитие проекта.
В С соблюдение АПИ только на совести программиста и сторонних утилит.
С++ позволяет на уровне языка реализовать инкапсуляцию, а RAII позволяет оградить программера от необходимости помнить о такой низкоуровневой части многих С АПИ, как освобожнение ресурсов.

Да,да конечно.
Как здесь:
http://web.archive.org/web/20060615055607/http://blogs.zdnet.com/threatchaos/?p=311
Ты как нибудь заморочься лишний раз, воспользуйся чужой тулзой codeviz и сравни C и C++ проекты с одинаковой функциональностей.
Очень поучительное зрелище.

Я смотрю вам в жизни вообще не попадалось нормальных С++ программеров. Но удивительно, что вы приписываете недостатки плохих программеров языку на котором они писали. Это мягко говоря немного нелогично. Впрочем в религиозных войнах логика редко задействуется.
Кстати вы тут в предыдущих сообщениях заявили что дескать мы, оппоненты, "утверждаем, что С++ круче всех". Так вот, мы вовсе не это утверждаем, а всего лишь утверждаем что С++ не хуже С. Это согласитесь не одно и то же.

Напишешь квин-программу под С++ где были бы полезны ООП плюшки и STL?
С той же эффективностью?

Зачем мне писать бесполезную программу. В ней такое понятие как надежность и развитие отсутствует, а значит ООП там не надо.
Я пишу программы полезные. А любая полезная программа имеет свойство развиваться. И вот тогда и вступает в силу ООП, которое позволяет один раз написать модуль, и забыть, а при расширении функциональности добавлять новые модули, не меняя старых, а значит не отлаживая или тестируя их заново.

Вот в последнем проекте, который был изначально прототипирован на Перле, я удачно разбил все на компоненты, так что постепенно модуль за модулем все перевел на С++ на каждом этапе сохраняя работоспособность проекта. А потом еще несколько раз расширялись требования к функциональности. И каждый раз ни один юниттест не сломался. Вот вам и ООП.
При этом была достигнута производительность в два раза выше требуемой(это сетевой сервер 20000 запросов/с на рабочий процесс, для сравнения nginx на этом же оборудовании давал 10000, хотя конечно их сравнивать некорректно, но видно что производительность на сходном уровне). Это при том что я писал прикладной код не оптимизируя специально, думал заняться этим позже.
Над libevent, сокетами и файлами были реализованы RAII обертки. Во всем коде и сетевом и прикладном были использованы куча контейнеров и алгоритмов из STL. Никаких delete в коде - все boost::shared_ptr. И конечно же исключения. Все как вы "любите"
Если бы я писал это на С, то пришлось бы всю эту низкоуровневую хрень реализовывать, отлаживать и поддерживать. На что ушло бы еще столько времени, сколько заняла прикладная часть. А смысла в этом не было бы никакого - программа и так работает достаточно быстро, зато практически весь код - прикладной, и с самого начала никаких утечек (извините не пользуюсь сторонним софтом для борьбы с ними за ненадобностью).

[Ull9]

Цитата:
Сообщение от Ull9
в F-35 15 млн строк кода. надо было бы больше написали бы больше. память практически не ограничена.
.....
А какого черта тогда на джаве не пишут?
Скорость разработки по любому будет выше.

к чему эти дешевые трюки, ты же прекрасно знаешь
что у военных код дла авионики пишется на С/С++ плюс некоторые компоненты на Ада.

[Ull9]

не то что много и полно, но есть еще куски старого сертифицированного кода писался на аде.
недавно систему управления для Хитроу (есть такой аэропорт возле лондона) сдали в эксплуатацию - полностью на аде.

недавно узнал что живет еще язык PL/1. это вообще археология. страховые риски на нем считают. и требтся программеры.

хех

[Parsifal]

Присоединяюсь к большинству - использую STL

[valheru]

Топикстартер зря STL и Boost в одну кучу свалил. STL в C++ проекте использовать нужно. В boost'e есть полезные вещи, но свет клином на нем не сошелся.

[Ull9]

Проблема с BOOST в том что уж очень он иногда удлинняет время компилации.
как то пользовался ихней лямбдой - код обьектные файлы растут как на дрожжях.
и компилится часами.

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

[18-я весна]

Проблема с BOOST в том что уж очень он иногда удлинняет время компилации.
как то пользовался ихней лямбдой - код обьектные файлы растут как на дрожжях.
и компилится часами.

Это проблема С++, а не Boost. Следствие унаследованной из С source-based модуляризации (которая в С отлично работает из-за эффективности компиляции - язык простой).

Будем ждать когда D встанет на ноги, в нем многие проблемы С++ (и эта) решены.
К сожалению надежд на это мало.

[Гай Монтего]

эх, таки меня это С++ с STLем таки нашло.

[homo ludens]

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

Мосье считает что не совершает ошибок и потому не пользуется QA?
И не стыдно об этом говорить так громко?
Или все-таки пользуется QA, но не автоматическим, как я, а живым тестером?
Тогда в чем профит?
Открою тайну, ни у одного программиста в мире нет утечек, если их наличие определяет он сам, а не внешний тестер или объективная программа.

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

Вы плохо знаете историю ООП (начинавшегося после забытого Smalltalk как ОО-дизайн).
Большинство ООП фишек были известны до ООП. Отцы-основатели собрали это в религию и добавили массовое использование ISA отношения (известного сейчас как наследование), впрочем позже верховные жрецы сменили точку зрения и начали рекомендовать использовать вместо него композицию.
Огромная куча проектов писалась на паттерне "Реактор" до того как этот паттерн изобрели, просто никому в голову не приходило дать этому имя. А уж инкапсуляция была еще в до-синклерных кодах, кто занет что такое "шапка джампов" - подтвердит.
Проектирование - это процесс разбиения графа на компоненты. Он может (и должен) быть автоматизирован. Но тогда мы забудем о программировании как о искусстве, вдобавок неплохо оплачиваемом. Этого не хочет никто из нас.
Отсюда такие монстры как ООП, безудержное языкотворчество при отсутствии прогресса в DSL и т.п.
Но когда-то это будет сделано и вся эта школа ООП радостно пойдет лесом.

А то что API должно быть минимально - я согласен ( с некоторыми оговорками, впрочем, минимальность зависит от метрики, которая не так уж и очевидна). Я больше пытаюсь мимнимизировать разбиение графа проекта с учетом числа Миллера http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two. В моем видении оптимальное API - это оптимальное decision tree.

Я смотрю вам в жизни вообще не попадалось нормальных С++ программеров. Но удивительно, что вы приписываете недостатки плохих программеров языку на котором они писали. Это мягко говоря немного нелогично.

Т.е. высказывание Вирта, утверждавший о том, что "С++ полностью уничтожает способность программиста к структурному мышлению" тебе незнакомо?
И эпичный тред Торвальдса, где он недобро отзывался о ментальном багаже плюсовиков ты не читал?
И не знаешь того, что в достаточно редких наездах обычно ругают не С++ как язык, а те повреждения, которые он наносит мозгам.
Наезды впрочем редки по понятной причине - работать всем хочется, а поссорившись с жрецами новой религии имеешь очень веселые шансы трудоустройства.
Кстати, как ты думаешь, почему тот call graph висит в вебархиве, а не там где ему положено?
Он между прочим на свое место два раза возвращался. И два раза опять снимали.

Кстати вы тут в предыдущих сообщениях заявили что дескать мы, оппоненты, "утверждаем, что С++ круче всех". Так вот, мы вовсе не это утверждаем, а всего лишь утверждаем что С++ не хуже С. Это согласитесь не одно и то же.

Хуже или нет, определяется не нашими высказываниями, а конкретной метрикой.
В мере скорости разработки С++ лучше С в среднем особенно при нечетких требованиях и плохой постановке.
В скорости рефакторинга С++ лучше С.
В скорости компиляции С++ хуже С.
В связности проекта С++ хуже С в среднем (хотя для крупных, рыхлых и гетерогенных проектов может быть обратное).
В LOC-метрике средний проект при одинаковой функциональности С++ хуже С - сравни "правильно написанный" hello world на С и С++. Темплейты улучшают соотношение, но не меняют его.
В мере взаимозаменяемости программиста С++ лучше С, но это заслуга скорее школы подготовки и массовости плюсовиков.
В мере времени, необходимом для подготовки программиста с нуля - С++ хуже С.
В мере эффективности программы С++ не лучше С по крайней мере, а в среднем реально хуже.
В мере повторного использования кода С++ значительно хуже С.
Говорят, еще С++ удобней С. Но вот это как раз та метрика, которая субъективна и измерению не поддается.

И еще.
Вы не только утверждаете, что он круче всех. Вы это делаете, как тот китаец. На практике. Выражение " я не хочу думать над реализацией" встречается в постах плюсовиков чуть чаще чем банан в снах дочки Фрейда. Хотя и реже чем в постах джавистов.
И мне несколько странно видеть людей, гипнотизирующих себя мантрой "не хочу думать" но тратящих свое время не на код, а на раздумья как бы еще оградить программиста от еще чего нибудь.
Зато нисколько не странно видеть результат - ореховую скорлупу, через которую не пробиться и замкнутые решения, закрытые для языка.
Вот пример - в одном из постов здесь кто-то заметил, что лямбды - это крутость неимоверная и новье. Блин, им сто лет в обед, это дерьмо мамонта печальное, если тебе нужна анонимная функция - то напиши ее и забудь ее имя.
Но для плюсовика - это крутость и новое. Потому что в С++ это крутость и новое, а вне С++ жизни нет. А через 5 лет те же люди скажут, что их лямбды правильные, а те, которые в лиспе и у Черча - неправильные.
Второй пример - для тебя пользование сторонними утилитами - зло. Что неявно предполагает постоянное написание того, что уже давно есть.
Либо вечный поиск в Boost, большей частью безуспешный.
Знаешь сколько раз я слышал слова "Зачем мы будем пользоваться этим, давай я напишу свое"?
Ты считаешь это правильным?

Зачем мне писать бесполезную программу. В ней такое понятие как надежность и развитие отсутствует, а значит ООП там не надо.
Я пишу программы полезные. А любая полезная программа имеет свойство развиваться. И вот тогда и вступает в силу ООП, которое позволяет один раз написать модуль, и забыть, а при расширении функциональности добавлять новые модули, не меняя старых, а значит не отлаживая или тестируя их заново.

Ага.
Меня всегда восхищала наивность С++ программистов, увлеченно рассказывающих об улучшенном повторном использовании кода на С++, пишущих очередную инкарнацию чего-либо и в упор не замечающих миллионы надежных роутеров с идентичным IP стеком, написанных на С.
При том, что С++ аналогов столь эффективного повторного использования кода я как-то не встречал.
Как впрочем и аналогов самого кода - человек пишущий TCP стек (реально сложный) на STL контейнерах имхо будет таким же идиотом как тот китаец.
Почему большинство research библиотек пишутся на С?
И почему они работают лучше и находятся в эксплуатации дольше чем С++ объекты?
Может быть потому, что в обычном языке либа доступна из любых других языков поддерживающих стандартную линковку?
А объект С++ - только для С++ и (если не лениться) пайтона?
И нафига это развитие, если в 90% случаев можно написать и забыть и оно будет работать годами? Я подозреваю, что если бы код роутеров развивался в твоем понимании развития - интернет бы остановился.

Вот в последнем проекте, который был изначально прототипирован на Перле, я удачно разбил все на компоненты, так что постепенно модуль за модулем все перевел на С++ на каждом этапе сохраняя работоспособность проекта. А потом еще несколько раз расширялись требования к функциональности.
И каждый раз ни один юниттест не сломался. Вот вам и ООП.

Хорошее обобщение, православное.
А я в прошлом году купался в красных плавках и не утонул. Вот вам и красные плавки.

А теперь по проекту.

Как говорили программисты на Дельфи - мы бы могли написать все, если бы для этого были компоненты.
Надеюсь всем понятно, что при написании самого libevent (С-шного) ни один STL контейнер не пострадал?
И получается что ядро твоего быстродействия с STL никак не связано.
В общем если бы ты написал ядро на epoll - я бы может еще понял твои аргументы.
А на libevent - извини.
Хотя если С10К перекрыл - уже хорошо. Производительность ты дал на одно ядро или на весь комп?

Кстати, а чего перл для прототипа?
Вроде на пайтоне проще модули с С++ сращивать.
Я собственно начал резать свои прототипы на перле как раз поэтому, когда полпроекта еще на перле, пол- на С, совместная работа несколько напряжна, не говоря об тестировании.
И swig не очень помогает...
Сейчас только алгоритмы так прототипирую.

Никаких delete в коде - все boost::shared_ptr.

А я вот от talloc отказался недавно, хотя по сравнению с его возможностями boost::shared_ptr - детский сад...
И все равно - ни одного разрыва. Тьфу, утечки.

Я в следующем посте опишу свой текущий проект и попрошу совета, где там можно использовать STL или Boost.

А теперь про RAII.

Блин, объясните мне, почему для правильного расположения ресурсов нужно изобретать паттерн, а не просто правильно расположить ресурсы?
Ежу понятно, что захват и освобождение ресурсов должны быть "скобками", т.е каждому захвату должно соответствовать освобождение (если не мультипоток, когда захват и освобождение асинхронны в разных потоках). И понятно, что всегда есть самый внешний блок, в котором идут захват и освобождение и блоки (ровно по одному), группирующие "транзакции" захватов и освобождений.
И понятно, что если выполнять соглашение - называть любой захват допустим acquireXxxYyy, а соответствующее освобождение - releaseXxxYyy - то достаточно тупейшего сканера на hooks/start-commit в svn и код с неправильным захватом или неосвобожденным ресурсом даже не закоммитится.
А если еще вспомнить например такую вещь как http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.86.8530&rep=rep1&type=pdf
нашедшую неосвобождение ресурса (не памяти!) в миллионах строк кода Linux kernel, то становится понятно, что RAII - это детский сад по сравнению с возможностью статической проверки исходников, в принципе невозможной на С++ по причине нелокального кода и переусложненного синтаксиса.
Кстати этот майнер построен на структурах данных изобретенных в этом тысячелетии. Но почему-то авторы их написали на С. Не на С++. И без STL. Странно, с чего бы это?

[homo ludens]

Ну и раз начали рассказывать про свои проекты - я расскажу про свои задачи.
Может гуру STL и Boost просветят.

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

Итак, у меня в проекте используются несколько видов хеш-таблиц. Их почему-то STL-щики считают трудными для самостоятельного написания, хотя имхо rb-tree сложнее будут.

Тип 1. Функциональный кеш.
Есть функция, которая очень долго считается. Надо поддерживать ее кэш для уже выполненных вычислений.
Кэш должен быть очень быстрый, фиксированного размера, LRU, запрос/вставка за O(1) без коллизий.

Тип 2. Константный read-only хеш. Есть набор ключевых слов, которые ищутся в потоке документов. Индексировать документы нельзя - они появляются и пропадают в потоке.
Слов (точнее фраз) около 1000, может быть больше.
Ключевые слова известны до компиляции, в рантайме изменены быть не могут.
Запрос на проверку слова должен выполняться за константное время O(1) без коллизий.

Тип 3.
Аналогично типу 2, но ключевых слов 10^8
again O(1) без коллизий

Тип 4. ультракомпактный хеш с константным доступом.

Я сюда скопирую задачку из собеседования.
Есть министерство образования африканской страны, контролирующее ВУЗы.
Есть студенты, каждый из которых два раза в год пишет реферат/курсовик/диплом.
Задача - прога для антиплагиата.
Реферат считается плагиатом если у него найдено два или более абзацев полностью (с точностью до \s*) совпадающие с какими-то абзацами в референтной базе данных.
Есть референтная база данных, в полмиллиона абзацев.
Длина абзаца в существующей базе до 64К, в новых документах не специфицирована.
Программа должна проверять по базе реферат и если он чистый - то добавлять его в базу.
Проверка абзаца в базе (и вставка) должны занимать O(1) по времени.

А так как страна африканская и бедная - то программа должна занимать одну трехдюймовую дискету емкостью 1.44М
Вместе с базой.

Гуру ООП, расскажите как мне сделать эти вещи на STL, и я уйду просветленный славя Бодхисаттву Страуструпа и четырех Будд Шаблонов.
Про Boost я просто промолчу. Пока.

[Гай Монтего]

абзацами в референтной базе данных.
Есть референтная база данных, в полмиллиона абзацев.
Длина абзаца в существующей базе до 64К, в новых документах не специфицирована.
Программа должна проверять по базе реферат и если он чистый - то добавлять его в базу.
Проверка абзаца в базе (и вставка) должны занимать O(1) по времени.

А так как страна африканская и бедная - то программа должна занимать одну трехдюймовую дискету емкостью 1.44М
Вместе с базой.

а чем перепаковать такие 64К абзацы, чтобы они влазили на такую дискету если их там с полтора миллиона?

[18-я весна]

Мосье считает что не совершает ошибок и потому не пользуется QA?
И не стыдно об этом говорить так громко?
Или все-таки пользуется QA, но не автоматическим, как я, а живым тестером?
Тогда в чем профит?
Открою тайну, ни у одного программиста в мире нет утечек, если их наличие определяет он сам, а не внешний тестер или объективная программа.

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

Вы плохо знаете историю ООП (начинавшегося после забытого Smalltalk как ОО-дизайн).
Большинство ООП фишек были известны до ООП. Отцы-основатели собрали это в религию и добавили массовое использование ISA отношения (известного сейчас как наследование), впрочем позже верховные жрецы сменили точку зрения и начали рекомендовать использовать вместо него композицию.
Огромная куча проектов писалась на паттерне "Реактор" до того как этот паттерн изобрели, просто никому в голову не приходило дать этому имя. А уж инкапсуляция была еще в до-синклерных кодах, кто занет что такое "шапка джампов" - подтвердит.
Проектирование - это процесс разбиения графа на компоненты. Он может (и должен) быть автоматизирован. Но тогда мы забудем о программировании как о искусстве, вдобавок неплохо оплачиваемом. Этого не хочет никто из нас.
Отсюда такие монстры как ООП, безудержное языкотворчество при отсутствии прогресса в DSL и т.п.
Но когда-то это будет сделано и вся эта школа ООП радостно пойдет лесом.

Не пойму причем здесь эта лекция про историю и про будущее.
Я не вижу противоречия с тем что я сказал.

Т.е. высказывание Вирта, утверждавший о том, что "С++ полностью уничтожает способность программиста к структурному мышлению" тебе незнакомо?
И эпичный тред Торвальдса, где он недобро отзывался о ментальном багаже плюсовиков ты не читал?

Мнение указанных авторитетных специалистов относительно С++ мне известны. Но не является для меня аргументом. Можно придумать массу субъективных объяснений их нелюбви к С++.
Например, многим людям свойственно ненавидеть чужаков, а все незнакомое или непонятное вызывает страх.

Кстати, как ты думаешь, почему тот call graph висит в вебархиве, а не там где ему положено?
Он между прочим на свое место два раза возвращался. И два раза опять снимали.

Потому что это просто флейм.
Нельзя судить по конкретным программам о языке.
Нужна статистика.

Хуже или нет, определяется не нашими высказываниями, а конкретной метрикой.
В мере скорости разработки С++ лучше С в среднем особенно при нечетких требованиях и плохой постановке.
В скорости рефакторинга С++ лучше С.
В скорости компиляции С++ хуже С.
В связности проекта С++ хуже С в среднем (хотя для крупных, рыхлых и гетерогенных проектов может быть обратное).
В LOC-метрике средний проект при одинаковой функциональности С++ хуже С - сравни "правильно написанный" hello world на С и С++. Темплейты улучшают соотношение, но не меняют его.
В мере взаимозаменяемости программиста С++ лучше С, но это заслуга скорее школы подготовки и массовости плюсовиков.
В мере времени, необходимом для подготовки программиста с нуля - С++ хуже С.
В мере эффективности программы С++ не лучше С по крайней мере, а в среднем реально хуже.
В мере повторного использования кода С++ значительно хуже С.
Говорят, еще С++ удобней С. Но вот это как раз та метрика, которая субъективна и измерению не поддается.

И еще.
Вы не только утверждаете, что он круче всех.

Извините, но я нигде такого не утверждал. А вот вы чуть выше подробно расписали кто и в чем круче.
Для меня же и С и С++ это инструменты. Надо будет - с удовольствием напишу и на С. И да, я видел в своей жизни кучу примеров как человек обсирал С++ а при этом сам писал на С абсолютно нечитаемый код.
Но я никаких выводов из этого не собираюсь делать, т.к. не карандаш пишет, не пистолет стреляет и не ЯП заставляет отключать мозги принаписании программ.

Знаешь сколько раз я слышал слова "Зачем мы будем пользоваться этим, давай я напишу свое"?
Ты считаешь это правильным?

Я от вас даже их слышал в этом топике, про хештаблицы

Ага.
Меня всегда восхищала наивность С++ программистов, увлеченно рассказывающих об улучшенном повторном использовании кода на С++, пишущих очередную инкарнацию чего-либо и в упор не замечающих миллионы надежных роутеров с идентичным IP стеком, написанных на С.
При том, что С++ аналогов столь эффективного повторного использования кода я как-то не встречал.

Все просто: большинство ОС во времена активного внедрения TCP/IP были написаны на С. Вот и реализовали на С.
Был бы тогда популярен С++, точно столько бы просуществовали реализации на С++.

Как впрочем и аналогов самого кода - человек пишущий TCP стек (реально сложный) на STL контейнерах имхо будет таким же идиотом как тот китаец.

Что вы привязались к STL.
STL используется в прикладном коде. А служебный (в т.ч. и RAII обертки) может быть написан на голом С++ он же С с классами.

Почему большинство research библиотек пишутся на С?
И почему они работают лучше и находятся в эксплуатации дольше чем С++ объекты?
Может быть потому, что в обычном языке либа доступна из любых других языков поддерживающих стандартную линковку?

А может потому что никакой надежности от них не требуется?

И нафига это развитие, если в 90% случаев можно написать и забыть и оно будет работать годами?

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

Я подозреваю, что если бы код роутеров развивался в твоем понимании развития - интернет бы остановился.

У вас слишком много домыслов. Пора останавливаться.

Надеюсь всем понятно, что при написании самого libevent (С-шного) ни один STL контейнер не пострадал?
И получается что ядро твоего быстродействия с STL никак не связано.

Так я как раз и говорил, что STL не влияет на скорость.

В общем если бы ты написал ядро на epoll - я бы может еще понял твои аргументы.
А на libevent - извини.

Странный аргумент, учитывая что libevent это всего-лишь обертка практически никак на производительность не влияющая.
Я ж написал, достигнута производительность, сравнимая с аналогичными программами написанными на С. При этом без ограничений связанных с производительностью, а просто там где было необходимо, применялся STL.

Хотя если С10К перекрыл - уже хорошо. Производительность ты дал на одно ядро или на весь комп?

Одно ядро.

Кстати, а чего перл для прототипа?
Вроде на пайтоне проще модули с С++ сращивать.
Я собственно начал резать свои прототипы на перле как раз поэтому, когда полпроекта еще на перле, пол- на С, совместная работа несколько напряжна, не говоря об тестировании.

Я пайтон не знаю в объеме достаточном для быстрого прототипирования.
А с перлом и интеропом с С++ у меня не возникало никаких проблем.

И swig не очень помогает...

Я XS модули вручную пишу.

А теперь про RAII.
Блин, объясните мне, почему для правильного расположения ресурсов нужно изобретать паттерн, а не просто правильно расположить ресурсы?
Ежу понятно, что захват и освобождение ресурсов должны быть "скобками", т.е каждому захвату должно соответствовать освобождение (если не мультипоток, когда захват и освобождение асинхронны в разных потоках).
И понятно, что всегда есть самый внешний блок, в котором идут захват и освобождение и блоки (ровно по одному), группирующие "транзакции" захватов и освобождений.

Есть куча примеров, когда нет никаких "скобок". И далеко не только в многопоточности. Например при совместном владении ресурсом несколькими контейнерами. Или при передаче владения.
Так что ваше "Ежу понятно" просто напросто не работает, в довольно таки тривиальных случаях. Потому что статического контроля почти всегда недостаточно для проверки утечек. Требуется run-time проверка.

И понятно, что если выполнять соглашение - называть любой захват допустим acquireXxxYyy, а соответствующее освобождение - releaseXxxYyy - то достаточно тупейшего сканера на hooks/start-commit в svn и код с неправильным захватом или неосвобожденным ресурсом даже не закоммитится.

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

А если еще вспомнить например такую вещь как http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.86.8530&rep=rep1&type=pdf
нашедшую неосвобождение ресурса (не памяти!) в миллионах строк кода Linux kernel, то становится понятно, что RAII - это детский сад по сравнению с возможностью статической проверки исходников, в принципе невозможной на С++ по причине нелокального кода и переусложненного синтаксиса.

Еще не известно, сколько он пропустил утечек о которых я выше сказал.

Кстати этот майнер построен на структурах данных изобретенных в этом тысячелетии. Но почему-то авторы их написали на С. Не на С++. И без STL. Странно, с чего бы это?

Может авторы не владеют С++ и поэтому не стали связываться с ним?
Можно придумать кучу причин никак не связанных со свойствами самих языков.

[18-я весна]

Итак, у меня в проекте используются несколько видов хеш-таблиц. Их почему-то STL-щики считают трудными для самостоятельного написания, хотя имхо rb-tree сложнее будут.

Не хочу вас разочаровывать, но как раз стандартных хеш-таблиц в STL нет, поэтому их обычно приходится реализовывать при написании кроссплатф. кода.
Поэтому странно слышать что STLщики боятся этого. Как я выше в топике писал, я когда надо могу и хеш-таблицу сделать.
А вот rb-tree как раз в STL есть

Тип 1. Функциональный кеш.
Есть функция, которая очень долго считается. Надо поддерживать ее кэш для уже выполненных вычислений.
Кэш должен быть очень быстрый, фиксированного размера, LRU, запрос/вставка за O(1) без коллизий.

Тип 2. Константный read-only хеш. Есть набор ключевых слов, которые ищутся в потоке документов. Индексировать документы нельзя - они появляются и пропадают в потоке.
Слов (точнее фраз) около 1000, может быть больше.
Ключевые слова известны до компиляции, в рантайме изменены быть не могут.
Запрос на проверку слова должен выполняться за константное время O(1) без коллизий.

Тип 3.
Аналогично типу 2, но ключевых слов 10^8
again O(1) без коллизий

Тип 4. ультракомпактный хеш с константным доступом.

В любой хеш таблице используется как минимум один массив - индексатор бакетов. Вот его можно std::vector-ом реализовать.
Если ключи строковые - std::string.
Ну и т.д.
А по конкретным алгоритмам и структурам для ваших задач - если бы мне набо было решать, то я посмотрел бы в справочнике принцип, а закодировать - тут проблем нет.

Я сюда скопирую задачку из собеседования.
Есть министерство образования африканской страны, контролирующее ВУЗы.
Есть студенты, каждый из которых два раза в год пишет реферат/курсовик/диплом.
Задача - прога для антиплагиата.
Реферат считается плагиатом если у него найдено два или более абзацев полностью (с точностью до \s*) совпадающие с какими-то абзацами в референтной базе данных.
Есть референтная база данных, в полмиллиона абзацев.
Длина абзаца в существующей базе до 64К, в новых документах не специфицирована.
Программа должна проверять по базе реферат и если он чистый - то добавлять его в базу.
Проверка абзаца в базе (и вставка) должны занимать O(1) по времени.

А так как страна африканская и бедная - то программа должна занимать одну трехдюймовую дискету емкостью 1.44М
Вместе с базой.

Гуру ООП, расскажите как мне сделать эти вещи на STL, и я уйду просветленный славя Бодхисаттву Страуструпа и четырех Будд Шаблонов.

Странная задача. Видно что надуманная. Я с такими сразу отшиваю.
1) O(1) для такого класса задач слишком жирно будет (особенно учитывая "два раза в год" ). Достаточно O(log n)
2) до 64К - почему вообще ограничение? для отвлечения внимания?
3) 1.44М - это вообще бред; если речь идет о таких лимитах, то могли бы хоты бы задачу про какие-нибудь микроконтроллеры придумать

Конечно такую задачу в жизни я бы делал не на С и не на С++, а на БД ориентированных языках. Например PowerBuilder+Firebird. И уж конечно без лимита диска.
А извращаться и пытаться упаковать базу до двух байт на абзац, это я допускаю что может и возможно, но как только понадобится хранить какую нибудь дополнительную инфу не привязанную к абзацам весь алгоритм затрещит по швам.

[homo ludens]

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

Не в первый раз привожу пример - бывают ситуации, когда память автоматической переменной очищается, а деструктор не вызывается.
Соответственно утечка гарантирована. Экзотика, да. Но бывает.

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

По линукс - бесплатно.
Включая отслеживание неинициализированных переменных, race condition, обращение к невыделенной памяти, незакрытые файлы и т.п.
Полная виртуальная машина.
valgrind.org
Просто запускаем valgrind --leak-check=full ./yourprogram

Потому что это просто флейм.
Нельзя судить по конкретным программам о языке.
Нужна статистика.

Для этого надо выбрать метрику и сравнивать по выборке программ.
Собственно по некоторым метрикам я уже список дал.

Извините, но я нигде такого не утверждал. А вот вы чуть выше подробно расписали кто и в чем круче.
Для меня же и С и С++ это инструменты. Надо будет - с удовольствием напишу и на С. И да, я видел в своей жизни кучу примеров как человек обсирал С++ а при этом сам писал на С абсолютно нечитаемый код.

Вот если бы у тебя аргументом было - неработающий код, я бы тебя понял.
Я в другой ветке уже приводил пример двух программ на С++ (OpenDT) и на С (c4.5).
Вторая абсолютно нечитаема.
Первая написана отлично.
Только вторая работает, а первая - нет.
И поэтому ПРАКТИЧЕСКИ ВСЕ люди, работающие с данной областью знают что такое с4.5 и хоть раз ей пользовались.
А OpenDT не знает никто.
Не может быть аргументом - читаема ли программа, "правильно" ли она написана, в полной ли мере она использует новые парадигмы и т.п.
Гамбургский счет - работает она или нет.
Все.
Я знал одного гика, которы все локальные переменные называл ____ с разным количеством подчеркиваний и код его не читался даже после литра красного. Зато все работало, а лазить в его код никому не надо было - задачи у него были такие, что все равно никто бы не полез.

Но я никаких выводов из этого не собираюсь делать, т.к. не карандаш пишет, не пистолет стреляет и не ЯП заставляет отключать мозги принаписании программ.

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

Я от вас даже их слышал в этом топике, про хештаблицы

Это потому что у всех первый вопрос - а ты сам пишешь map и hash_map?

Все просто: большинство ОС во времена активного внедрения TCP/IP были написаны на С. Вот и реализовали на С.
Был бы тогда популярен С++, точно столько бы просуществовали реализации на С++.

Не, не катит, BeOS на С++ был.
И новых имплементаций со времен Berkeley было несколько.
Просто уровень оптимизации там чуть другой.

А может потому что никакой надежности от них не требуется?

Но при этом они надежней и производительней их С++ и Java клонов.

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

Собственно это решается не ООП, а abstraction layer...
Но кому как нравится...

Так я как раз и говорил, что STL не влияет на скорость.

И тем не менее предложенные мной задачки с O(1) STL не решил...

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

А вот их конкуренты (libev) считают, что он слишком медленный, так как использует два лиших вызова ядра.

Тут вопрос в другом. libevent показывает экстремальную производительность только там, где это позволяет платформа.
ЕМНИП это в первую очередь Linux/epoll и BSD/kqueue.
Т.е. его имеет смысл использовать в двух случаях.
1. требуется портирование/мультплатформенность
2. Нужно быстро что-то написать не заморачиваясь и есть опыт работы на libevent.

Там где требуется производительность имхо проще зафиксировать платформу и написать свой event loop на epoll/kqueue (это 100-200 строк кода без таймеров).
Т.е. я вообще считаю что задача однозначно определяет способ решения.
Хотя конечно возможны варианты, таймеры несколько усложняют и т.п.

Я ж написал, достигнута производительность, сравнимая с аналогичными программами написанными на С. При этом без ограничений связанных с производительностью, а просто там где было необходимо, применялся STL.

На самом деле - молодцы, полная уважуха.
Другой вопрос, что c10k - это обработка одного коннекта 100us.
За это время допустим дисковых операций много не сделаешь, в основном это работа с памятью.

Я XS модули вручную пишу.

Не, вот на этом этапе мне несколько поплохело, я начал искать автоматический генератор оберток, нашел swig и понял, что он не для перла...
Все-таки ручная работа чем-то отталкивает.

Есть куча примеров, когда нет никаких "скобок". И далеко не только в многопоточности. Например при совместном владении ресурсом несколькими контейнерами. Или при передаче владения.

Эээ нет, при передаче владения этот процесс аналогичен паре acquire/release с учетом счетчика ссылок.
Принимающий делает acquire с инкрементом, передающий делает release(декремент).
Аналогично при совместном владении.
Так что и здесь все в порядке.
Я ж говорю, скобки решают практически везде.
В мультипотоке нельзя, там по другому решается.
Собственно всегда есть точка в программе где объект возникает/инкрементирует счетчик/передается и есть точки где он разрушается/декрементируется/принимается.
Соответственно они всегда должны быть парными на flow graph.
И идея сделать их "скобками" имхо вполне разумна.
В конце-концов это работает с автоматическими переменными, почему это не может работать в другом месте?

Так что ваше "Ежу понятно" просто напросто не работает, в довольно таки тривиальных случаях. Потому что статического контроля почти всегда недостаточно для проверки утечек. Требуется run-time проверка.

Не, статика может проверить все ветки, включая те в которые рантайм никогда не заглянет.
И кроме того, как раз для RAII статика может проверить абсолютно все.
Но не в С++.
И вот почему.
Для проверки на С достаточно одной функции, чтобы сказать, нарушает эта функция скобки или нет.
А для С++ надо знать весь проект - оверлоады, касты, конструкторы, деструкторы, они все скрыты и черта с два найдешь где они определены, и какие ресурсы в них берутся, а какие - освобождаются.
Т.е. IRL такая проверка на С++ (как и большинство статических проверок) нереальна.
Если бы на С++ был режим трансляции в С - тогда можно было бы делать такие вещи.
А так, увы.
Вообще программная обработка С++ исходников затруднена или просто бессмысленна.
В отличие от.
Qt-шникам даже пришлось написать свой метаобъектный компилятор, не удалось им удержаться в чистом С++.
Что в С решалось бы макропроцессором или кодогенератором.

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

То что работает - хорошо, а уж хуки репозитория - вообще вещь правильная .
Встроенные возможности языка не позволяют на 100% _доказать_ отсутствие ошибок выделения/освобождения.
А эта система - позволяет.
Именно на 100%.
Другой вопрос, что несоответствие скобок в одном блоке видно и невооруженным взглядом, поэтому при использовании указанной дисциплины даже сканер не нужен...

Еще не известно, сколько он пропустил утечек о которых я выше сказал.

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

Может авторы не владеют С++ и поэтому не стали связываться с ним?
Можно придумать кучу причин никак не связанных со свойствами самих языков.

Люди, публикующие новые алгоритмы обычно пишут сегодня либы С, либо минимальный С++ с интерфесами на С.
Вообще open-source либу выгоднее публиковать на С, чем на плюсах по указанной мною причине.
Плюсовой смогут пользоваться только плюсовики...

Не хочу вас разочаровывать, но как раз стандартных хеш-таблиц в STL нет, поэтому их обычно приходится реализовывать при написании кроссплатф. кода.
Поэтому странно слышать что STLщики боятся этого. Как я выше в топике писал, я когда надо могу и хеш-таблицу сделать.
А вот rb-tree как раз в STL есть

Я знаю, и даже знаю почему
Просто вместо хеш-таблиц все равно все юзают map.

По своему проекту будет отдельный пост.

[homo ludens]

Хэш-таблица 1

//! yes, this is cache size, really :-)
#define CACHESIZE	0x100000UL

//! very long function..... maxlen has same semantics as 'n' in str'n'cpy/str'n'cmp
double tormozzzz(const char*,int maxlen);

//! some fast hash function (i.e. Bernstein hash). maxlen as above
uint32_t hash(const char*,int maxlen);

//! cache
struct cacheItem
{
  char arg[MAXSIZE];
  double val;
} cache[CACHESIZE];

double getFunctionVal(const char* s)
{
  struct cacheItem* p=cache+(hash(s,MAXSIZE)%CACHESIZE);
// first predicate work in case of test uninitialized cache cell
  if(p->arg[0] && !strncmp(p->arg,s,MAXSIZE))
    return p->val;
  strncpy(p->arg,s,MAXLEN);
  retrun  p->val=tormozzzz(s,MAXSIZE);
}

STL в принципе не при делах.
И ничего здесь улучшить не могут.