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

NBN>>Конкретно я видел много самопала, но хороший был только мой. И то не весь
E>Ну весь не весь, но бывают "самопальные" контейнеры, которые, по крайней мере, не хуже STL уж точно...

Не, самопал не вариант. Я, например, изучил определенное количество популярных библиотек (BOOST, Qt, и проч.), включая STL ессно. Что-то очень хорошо, что еще не очень, что в процессе. Кое что применял и применяю на практике, кое что на примерах. Зато я это знаю. Знаю большинство проблем и их решение, знаю где мне быстро найти интересующую справочную инофрмацию. Знаю что по любой из этих библиотек я могу спросить здесь или где-либо еще — и мне ответят. Мне всего лишь надо будет привести версию используемой библы, компилятор и платформу. И этого хватит, чтобы мне помогли. Мне не нужно приводить тонну "самопального" кода, я не считаю что в нем остальные должны сидеть и копаться разбираться. Также как не считаю что я должен. Какие еще аргументы нужны?

Это удобно. Это плюс.

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

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

Это как нефть добывать. МОжно своими ведрами черпать и бурить лопатами кучей народу, все равно ведь окупиться

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

S>Вообще-то есть такая фишка: http://www.boost.org/libs/smart_ptr/enable_shared_from_this.html
S>Когда я про нее не знал (а может ее тогда просто не было), то написал свой гибрид shared+intrusive ptr. У который рефкаунт болтался в памяти отдельно от основного объекта, как у shared_ptr, что позволяло делать слабые указатели, но был доступен через сам объект (а не через обертку) как у intrusive_ptr, что позволяло многократно конструировать умный указатель из указателя на объект. Здесь та же фигня, но уже в библиотеке.
Да не таже фигня, нельзя слабый указатель в бусте сделать из простого указателя на объект. Крометого можно не аллокировать счётчик до тех пор пока слабые не понадобятся Еще засунуть enable_shared_from_this в виртуальный базовый класс и все есть, два плюса перед стандартным. Правда делитера нет, для грязных хаков

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

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


Просьба не воспринимать мои слова буквально. Они относятся только к пропагандам вида "STL, Boost и прос. зло потому что у нас без них все типа зашибись!"... Тут требуется сказать, что хорошо когда есть варианты, чтобы все конкретно в STL например не упиралось, но в качестве рекомендации самое то. Зачем создавать противоречия? Создай свою альтернативную библиотеку, покажи народу, выложи в свободный доступ, а уже ПОТОМ остальные разговоры. А безосновательные "а у нас..." только сбивают с толку.

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

E>2) ИМХО хуже не то, что он по памяти неэффективен, а то, что он не позволяет произвольно использовать код, в котором пользуются просто указатели. Хотя это всё решается конечно, но ценой усложнения то там, то сям.
E>Ну, например, просто указатели можно хранить как POD и особо не церемониться. С weak_ptr так уже не погоняешь...

Зависит от кода. Мне вот довольно много приходится работать с библиотеками, которые предоставляют почти что голый сишный интерфейс, и все у меня отлично уживаются вместе с shared_ptr.

You will always get what you always got
  If you always do  what you always did

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

E>Увы, есть пара подводных камней.
E>1) Довольно трудно ограничить использование разработчиками только того "что надо" из буста

есть такая штука — code review (она ведь у вас есть, не так ли?)

E>2) Когда гром таки грянет не всегда просто понять, а что же таки наиспользовали господа разработчики и что же из буста реально работает, и что использовани переносимо...
E>В этом смысле своя библиотека радикально лучше управляема и поддерживаема.
во-первых, буст

J>>Насчет поддерживать актуальность....Автоматика здесь слишком дорого может встать.
E>+1
E>Проблема не в том, что актуальность, а в том, что находятся ошибки и их надо править синхронно в своей версии. Вторая проблема в том, что разнеые части проекта заимствуют разные версии библиотеки (если она не поддерживается актуальной), а потом ты наблюдаешь довольно прикольные интерферреционные эффекты

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

E>>>Я не говорил про полный маразм вроде запрещения шаблонов, исключений или STL.
J>>А он-таки встречается в реальной жизни.
E>Ну я в реальной жизни встречал запрет в такой форме: "обоснуй, пожалуйста, выгоду от использования предлагаемого средства"

Значит, тебе везло с начальством

E>Ну часто так бывает, что "совсем нового кода" не бывает. А если он таки бывает, то никто не гарантирует, что в конце концов он не пересечётя со старым. Другое дело, что старый код лучше всё-таки поддерживать в хорошем состоянии и не забывать рефакторить при нужде.

Рефакторить существующий код тоже сплошь и рядом запрещено административно.
Ибо "оно сейчас в таком виде работает и приносит деньги."

E>Идея в том, что если в конторе нормально поставлено дело и она старая, то тами без буста и без STL всё более или менее нормально. А что ненормально -- выпрямляют, безотносительно к внедрению STL'я.

Чаще менее нормально, чем более. И выпрямлять ни у кого духа не хватает, наоборот, ненормальность объявляется священной коровой


E>У меня есть заметный опыт в переносе кода на разные платформы. А у нашей конторы такого опыта вообще вагоны. В том числе на экзотические и довольно убогие. Среди убогих были и такие, где не было возможности иметь конструкторы статических объектов и такие, гед не было исключений, и такие, где шаблоны были не супер. ИМХО "крутые" шаблоны тяжелее всего переносить в таком раскладе. Потому, что они весь код пронизывают и часто трудно понять что там должно произойти, если их оттуда отковырять.

Буст в этом смысле довольно неплох, кстати — там уже существует куча workarounds для разных странных платформ, и часто бывает так, что (если у тебя экхотическая платформа) один из этих хаков тебе подойдет (хаки эти включаются/выключаются соответствующими дефайнами в config.hpp). Буст все-таки разрабатывается и тестируется довольно интенсивно, особенно библиотеки общего назначения типа умных указателей и т.п. Пользователей буста все же всяко больше, чем любой доморощенной библиотеки, и условиях, в которых попробовали буст погонять, тоже больше, чем для самописной.

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

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

E>Короче мой выбор такой: Надо выбрать такой компромисный способ использования и шаблонов и исключений и конструкторов статических объектов (включая синглетоны и объекты из DLL), чтобы пользу более или менее всю иметь от этих механизмов, а зависить от них не очень драматически.
E>К сожалению STL в эту парадигму совсем не укладывается по многим причинам. Вот мы его и не используем

По каким конкретно, если не секрет?

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

E>

---

J>>Почему горячие? Ведь действительно стандартная библиотека и т.д. — посмотри драфт стандарта.
J>>Другое дело, что (вот ты меня все-таки хочешь вытянуть на этот долгий разговор, да?) с многопоточностью в С++ вообще большие проблемы, встроенные, в дизайне языка. И свет пока что виден только в C++0x — собственно, это главный приоритет следующего стандарта: нормальная поддержка многопоточности со стороны языка (атомарные типы, барьеры и т.д.)

E>Вот многопоточность -- это да. Только мне кажется, что C++ всё ранво для многопоточности будет не супер. Тут нас ещё ждут какие-то революции и свершения
E>Мне так кажется, что решения должны быть либо ориентированы на какую-то мегамногопроцессорную платформу, но тогда надо совсем другой язык писать, наверное функциональный какой-то, либо должна быть поддержка распараллеливания на каком-то очень высоком уровне. Типа на уровне запроса. Но тогда это скорее не к языку, а к ОС и библиотекам...

Не, это именно к языку. Пока не определена семантика базовых операций в многопоточном окружении — никакая библиотека тебе не поможет, останется только молиться, что у тебя все сработает правильно. Так что комитет занимается очень правильным делом.

А насчет языка для супер-параллельности — посмотри на Clik Думаю, тебе понравится

You will always get what you always got
  If you always do  what you always did

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

V>...Создай свою альтернативную библиотеку, покажи народу, выложи в свободный доступ, а уже ПОТОМ остальные разговоры. А безосновательные "а у нас..." только сбивают с толку.

Хорошие библиотеки обычно проприетарные и выложить их в общий доступ просто так нельзя.
Кроме того приватные библиотеки обычно хороши потому, что соответсвуют конторовскому стилю разработки. STl-то он общий очень. И понятно, что как общее решение проигрывает частному...

Ну а буст -- это вообще эксперементальная, бурно развивающаяся платформа. ИМХО от него зависеть немного страшновато...

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

E>поинт в том, что усложняется несколько весь работающий с shared/weak_ptr код, по сравнению с интрузивным указателем + просто указатель + продуманная схема владения объектами.

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

E>Лично мне, кстати, больше всего нравится такая конструкция:

E>1) Заводим аллокатор, который просто выдаёт память, сколько попросят из большого буфера (скажем докомичивает или довыделяет куски по мере исчерпания, не суть)
E>2) Какой-то алгоритм весь проделываем на таком аллокаторе. Всё, что аллокируется -- аллокируется там.
E>3) Результаты переносятся на другой аллокатор (или сразу на другом рожаются)
E>4) По окончании работы нашего алгоритма весе объекты "теряются", а всеь аллокатор грохается целиком.

E>Вот такая вот замена GC. Дёшево, быстро и сердито. Есть проблемы. Главная -- требуется поддержка такой парадигмы библиотекой, чего от STL добиться нелегко

А в чем проблема? В том, что все объекты аллокатора должны быть одинаковыми?

Я делал проще (в том проекте, в котором было запрещено вообще все, кроме жутких контейнеров на макросах). Просто читал из БД все объекты в один контейнер, и они там лежали. Все остальные контейнеры хранили голые указатели внутрь этого главного контейнера, и к этим указателям, ессно, никогда delete не применялся. По окончании работы все прибивалось, после чего уничтожался главный контейнер, уже со всем содержимым.

You will always get what you always got
  If you always do  what you always did

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

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

V>>...Создай свою альтернативную библиотеку, покажи народу, выложи в свободный доступ, а уже ПОТОМ остальные разговоры. А безосновательные "а у нас..." только сбивают с толку.

E>Хорошие библиотеки обычно проприетарные и выложить их в общий доступ просто так нельзя.
E>Кроме того приватные библиотеки обычно хороши потому, что соответсвуют конторовскому стилю разработки. STl-то он общий очень. И понятно, что как общее решение проигрывает частному...

Только в частном случае. В общем случае же выигрывает. СИтуация прямо один в один с тем временем когда был переход с С на С++, тоже самое почти .

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

E>Ну а буст -- это вообще эксперементальная, бурно развивающаяся платформа. ИМХО от него зависеть немного страшновато...

А ты прям предлогаешь либо вообще без буста, либо ВЕСЬ буст со всеми причиндалами — выжать из него все что только можно. Хотя второй вариант принесет вам дополнительные выгоды. Сказать какие? Прославитесь!

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

E>>1) Довольно трудно ограничить использование разработчиками только того "что надо" из буста
J>есть такая штука — code review (она ведь у вас есть, не так ли?)

А всё равно трудно. Например приходится поддерживать формальную какую-то структуру на тему о том, что можно, что нельзя, обучать экспертов, и т. д.

E>>В этом смысле своя библиотека радикально лучше управляема и поддерживаема.
J>во-первых, буст


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

E>>Ну я в реальной жизни встречал запрет в такой форме: "обоснуй, пожалуйста, выгоду от использования предлагаемого средства"
J>Значит, тебе везло с начальством
Да мне и с собой везёт в целом

J>Рефакторить существующий код тоже сплошь и рядом запрещено административно.
J>Ибо "оно сейчас в таком виде работает и приносит деньги."
И это правильно!!!
Тут, как и везде в инженерной деятельности, нужен разумный компромис

E>>Идея в том, что если в конторе нормально поставлено дело и она старая, то тами без буста и без STL всё более или менее нормально. А что ненормально -- выпрямляют, безотносительно к внедрению STL'я.
J>Чаще менее нормально, чем более. И выпрямлять ни у кого духа не хватает, наоборот, ненормальность объявляется священной коровой

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

J>Буст в этом смысле довольно неплох, кстати — там уже существует куча workarounds для разных странных платформ, и часто бывает так, что (если у тебя экхотическая платформа) один из этих хаков тебе подойдет (хаки эти включаются/выключаются соответствующими дефайнами в config.hpp). Буст все-таки разрабатывается и тестируется довольно интенсивно, особенно библиотеки общего назначения типа умных указателей и т.п. Пользователей буста все же всяко больше, чем любой доморощенной библиотеки, и условиях, в которых попробовали буст погонять, тоже больше, чем для самописной.

Ну я вот буст переносить не пробовал. А с STL имел проблемы регулярно

J>имхо, написать код, который будет нормально работать и с исключениями, и без, по-человечески невозможно.
Ты не понял. Нужно написать такой код, который легко модифицировать так, чтобы не было исключений...
Но это правда непросто. Это требует довольно комплексного подхода...

E>>К сожалению STL в эту парадигму совсем не укладывается по многим причинам. Вот мы его и не используем
J>По каким конкретно, если не секрет?
Ну долго это рассказывать. Правда долго и занудно. Кроме того тебе наверное многое покажется странным. Подходы же они только в комплексе работают...

Я приведу один всего пример. В библиотеках, которые мне нравятся, перекрывают ::new/::delete для того, чтобы всякими хитрыми способами управлять стратегиями аллокации. Это позволяет делать аналог GC некий во многих нужных нам "прожорливых по памяти" алгоритмах, скажем. Ну и вообще это много чего позволяет. Кроме того есть ещё такая метода, что при обработке запроса, ты регишь где-то в запросе все критические ресурсы, а все некритические (например память под локальные на запрос объекты) аллокируешь на специальнйо куче запроса. В случае, если всё гавкнулось, то освобождаешь зарегистрированные критические ресурсы, и грохаешь всю кучу запроса. Восстанавливаешься таким образом.
Обращаю внимание, что так можно восстановиться и при помощи исключения, и при помощи глобального goto...

E>>

---

E>>Вот многопоточность -- это да. Только мне кажется, что C++ всё ранво для многопоточности будет не супер. Тут нас ещё ждут какие-то революции и свершения
E>>Мне так кажется, что решения должны быть либо ориентированы на какую-то мегамногопроцессорную платформу, но тогда надо совсем другой язык писать, наверное функциональный какой-то, либо должна быть поддержка распараллеливания на каком-то очень высоком уровне. Типа на уровне запроса. Но тогда это скорее не к языку, а к ОС и библиотекам...

J>Не, это именно к языку. Пока не определена семантика базовых операций в многопоточном окружении — никакая библиотека тебе не поможет, останется только молиться, что у тебя все сработает правильно. Так что комитет занимается очень правильным делом.
Ну де факто на платформах, где есть многопоточность вообще, реализация языка всё определила уже. Ну есть там несколько тонких мест, вроде синглетона Майерса, ну и что? ИМХО сам по себе синглетон, в том числе и Майерса не нужен

J>А насчет языка для супер-параллельности — посмотри на Clik Думаю, тебе понравится
Да их много

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

Возьми Symbian-овские котейнеры и потрать минуту.
Или, ещё хуже, возьми Symbian-овские строки.
Даже после того как ты с ними разберёшься (день, не меньше) у тебя уйдёт не меньше недели чтобы просто привыкнуть ими пользоваться. А потом — ещё месяц чтобы довести процент ошибок которые ты делаешь при работе с ними до того же уровня, что и при работе со стандартными.

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

J>Зависит от кода. Мне вот довольно много приходится работать с библиотеками, которые предоставляют почти что голый сишный интерфейс, и все у меня отлично уживаются вместе с shared_ptr.

Ну много от чего зависит. Хотя я согласен, если сразу запроектировать proxy-объекты для того, что убивается само по себе, вполне можно и с shared_ptr всё сделать. Правда я не очень понимаю зачем тогда shared_ptr нужен, но если он таки удобен, то от чего бы и нет?

> S>Вообще-то есть такая фишка: http://www.boost.org/libs/smart_ptr/enable_shared_from_this.html
> S>Когда я про нее не знал (а может ее тогда просто не было), то написал свой гибрид shared+intrusive ptr. У который рефкаунт болтался в памяти отдельно от основного объекта, как у shared_ptr, что позволяло делать слабые указатели, но был доступен через сам объект (а не через обертку) как у intrusive_ptr, что позволяло многократно конструировать умный указатель из указателя на объект. Здесь та же фигня, но уже в библиотеке.
> Да не таже фигня, нельзя слабый указатель в бусте сделать из простого указателя на объект.

Можно. У weak_ptr есть конструктор, принимающий shared_ptr, shared_ptr можно получить из указателя.

> Крометого можно не аллокировать счётчик до тех пор пока слабые не понадобятся

Не нужны слабые указатели — пользуйся intrusive_ptr.

> Еще засунуть enable_shared_from_this в виртуальный базовый класс и все есть, два плюса перед стандартным. Правда делитера нет, для грязных хаков

Думаешь, виртуальные базовые классы бесплатные?

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


>> S>Вообще-то есть такая фишка: http://www.boost.org/libs/smart_ptr/enable_shared_from_this.html
>> S>Когда я про нее не знал (а может ее тогда просто не было), то написал свой гибрид shared+intrusive ptr. У который рефкаунт болтался в памяти отдельно от основного объекта, как у shared_ptr, что позволяло делать слабые указатели, но был доступен через сам объект (а не через обертку) как у intrusive_ptr, что позволяло многократно конструировать умный указатель из указателя на объект. Здесь та же фигня, но уже в библиотеке.
>> Да не таже фигня, нельзя слабый указатель в бусте сделать из простого указателя на объект.

S>Можно. У weak_ptr есть конструктор, принимающий shared_ptr, shared_ptr можно получить из указателя.
Конечно можно, но только 1 раз Если повторить этот процесс то создастся вторая копия счётчика ссылок

>> Крометого можно не аллокировать счётчик до тех пор пока слабые не понадобятся

S>Не нужны слабые указатели — пользуйся intrusive_ptr.
Просто так один тип, чтоб не думать.

>> Еще засунуть enable_shared_from_this в виртуальный базовый класс и все есть, два плюса перед стандартным. Правда делитера нет, для грязных хаков

S>Думаешь, виртуальные базовые классы бесплатные?
не бесплатные конечно, но иногда нужные. Можно и не виртуально наследовать если у обьекты только одного типа

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

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

Ну тогда воспользуйся bcp. Ты им вообще пользовался-то? Я нет, так что ничего сказать не могу.

E>Не, я в 96-97-м наглотался с нестандартной STL в составе тогдашних C++ компиляторов. Проще подождать. Вот станет tr1 частью стандарта, будет в составе компиляторов, можно будет от заказчиков требовать "От С++ компилятора требуется поддержка стандарта C++09, в частности, наличие библиотек tr1", тогда другое дело.

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

Ну и проще все-таки подправить уже написанную реализацию на boost::shared_ptr на использование std::shared_ptr, чем использовать сейчас что-то совершенно левое с иной идеологией, а потом переходить на std::shared_ptr.

E>Хотя наличие аналога RubyGems для C++ было бы лучше.

Feel free to submit, как говорится

E>Так что твои опасения не оправданны. Естественно, что при переходе на новую версию подпроекта происходит тестирование всего проекта. Но сам переход оказывается проще, когда автоматический тул скажет, что подпроект версии такой-то зависит от другого подпроекта версии такой-то.

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

E>Ну тут уж проще, имхо, место работы сменить. Если люди не понимают, за счет чего C++ отличается от C и какую пользу можно извлекать от RAII, шаблонов, STL-я и пр. -- то даже высокая оплата не в состоянии компенсировать безвозвратно утерянного времени, имхо.

Вот я и сменил

E>Так и я не призывал к бойкоту boost-а. Имхо, какая-то нетерпимость проявляется к тем, кто boost не используется. Вот это и не нравится.

Зависит от причин, по которым он (вернее, конкретные библиотеки из него) не используются. Если причина идиотско-административная — нетерпимость естественна.

J>>Но если ты начинаешь писать новый код, и вместо того, чтобы обойтись одной строчкой, тебе приходится неделю корпеть над _макросами_ и прогулками по куче (я не шучу, это случай из реальной жизни) — я не вижу ну ни одного вменяемого аргумента против этой строчки, за исключением "мы набираем дешевых идиотов, так что не умничай и гоняй макросы, как все"

E>Максим, а мы сейчас вообще о чем говорим? Макросы откуда-то взялись, проходы по куче...
О реальной жизни мы говорим, все о ней, родимой. Что я, что ты. Я работал в проекте, где были ублюдочные контейнеры на макросах. И ни в коем случае нельзя было применить шаблоны или STL даже в новом коде, потомму что де уже есть контейнеры, хоть и полное ..., но свои.

E>А в C++ -- как захочется, так и сделаешь.
Это если нет запрета сверху делать так, как хочешь.

E>Для меня, например, ACE -- это практически идеальное соотношение полезности библиотеки к сложности ее исполнения.
Слишком много в ней ограничений. Надо все время наследоваться от ее классов, и т.д.
Практически невозможно ее прикрутить к уже существуюшей программе в качестве альтернативного движка.

E>Crypto++ -- это уже перебор. А boost (в таких проявлениях, как spirit) -- это вообще overkill.

Кому как Мы вот используем спирит, чтобы парсить конфиги. Грамматика задается практически одной строчках, и на халяву получаешь контроль ошибок и гарантированно правильный парсинг. Соответственно мы не паримся о том, что нас текущий формат не удовлетворяет — идем и меняем, потому что парсилку проапдейтить — дело двух минут. А в предыдущем проекте (откуда я ушел) из доступных парсеров был только односимвольный токенайзер. И естественно, все конфиги были заточены под него, независимо от того, какой синтаксис был бы для данного конфига наиболее естественным.

E>Посему как-то modern C++ design как-то не по мне, сложновато, некрасиво местами.

Дело вкуса

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

J>>Надо исследовать. Естественно, представяя себе хотя бы примерно, через какие платформы придется пройти.

E>Бывают случаи, когда даже не представляешь. У меня было, как минимум, два случая, когда приходилось портировать код на платформы, о которых до этого я даже не слышал (в первый раз это была OS-9000, во второй -- HP NonStop).

Опять же, модульность помогает (если нет требования перенести весь код).

E>Так что то, что ты написал -- все правильно. Но жизнь преподносит интересные сюрпризы.
E>А на чистом C писать -- это уже слишком, лучше в технические писатели переквалифицироваться.

Это еще почему? Стройный простой язык, при известной дисциплине программирования, естественно.

E>>>Неоднократно. Только ведь заказчик -- он же всегда прав. Его не пугает даже то, что MS уже давно прекратила поддержку VC.6.0 (помнится, сие знаменательное событие произошло пару лет назад).

J>>Вообще странно, что заказчик диктует среду разработки. Вроде как, ему не шашечки должны быть нужны, а ехать. Ну да всякое в жизни бывает.

E>Да все просто -- мы ему библиотеки делаем, а они используют VC.6.0. Поэтому библиотеки должны работать под VC.6.0.
Ну, тут выбора действительно нет. Хотя опять же, некоторые части буста работают на шестерке абсолютно без проблем. Почему не использовать их —

E>Ну так драфт, он же не стандарт. Войдет в стандарт и начну шпиговать свои программы запчастями из tr1

Боюсь, не начнешь Скажешь — существующий код работает, менять нельзя

E>Просто хочу объяснить, что возможна точка зрения, согласно которой boost -- это всего одна из C++ных библиотек.
Это неправильная точка зрения. Буст — это _набор_ библиотек.
И какие-то из них действительно лучше существующих аналогов.

E>И может быть масса условий, при которых, например, boost::regex ничем не лучше pcre, boost::spirit -- antlr или bison/flex.
Может, конечно, кто ж спорит. Но если они равны для данной задачи — имеет смысл использовать буст, хотя бы потому, что, например, boost::regex уже в драфте стандарта.

E>Более того, есть целые фреймворки (ACE, Poco, wxWidgets, Qt, FOX), которые включают в себя очень и очень много всего. В том числе и того, что пытаются заново перетащить в boost. Еще можно понять, зачем boost-е своя реализация нитей и примитивов синхронизации. Но вот зачем в boost-е пытаются сделать asio не обращая внимания на ACE? Единственное объяснение: у ACE есть фатальный недостаток -- его писали не мы.

У АСЕ много фатальных недостатков, и главный — то, что это фреймворк. Т.е. если тебе нужно нечто, что уже не предусмотрено — тебе придется продублировать кучу кода.
И с чего ты взял, что не обращая внимания на АСЕ?
И с чего ты взял, что вообще есть такой критерий: "его писали не мы"? Да почти каждая новая включенная библиотека написана новым автором.
У тебя есть своя библиотека и она лучше всех остальных на эту тему? Feel free to submit! Только будь готов, что ее разберут по косточкам и ткнут носом во все темные или плохо реализованные места.

E>Да, так вот о boost-е. Мне кажется, что boost уже давно не столько библиотека (это ACE или Poco библиотеки), это социальный феномен. Это как "наш ответ Чемберлену" (в виде JVM, JDK и .NET). Мол все лучшее и прогрессивное в C++ концентрируется в boost-е.
E>Как центр консолидации усилий C++ников boost гораздо важнее, чем реализованные в нем вещи (имхо). И пусть так и будет. Пусть процветает, пухнет и монстроузнеет. Долгие лета, как говорится.
E>Только грусно становится, когда вдруг наталкиваешься на отношение: "Кто не с boost-ом, тот против нас".
E>Не правильно это.

Буст — это коллекция библиотек, которые будут понемногу включаться в Стандарт С++. Вот это — правильное определение.
Очевидно, что все хотят, чтобы в Стандарт вошло все самое лучшее и прогрессивное, или кто-то из присутствующих этого не хочет?

А с твоим имхом я ну никак не согласен, боюсь, оно основано на отсутствии у тебя опыта разработки с бустом.
Мне лично очень важны именно вещи, которые реализованы в нем, потому что от них напрямую зависит моя эффективность на работе.

И новые библиотеки проходят публичное обсуждение, прежде чем будут приняты. Хочешь повлиять — добро пожаловать.
Ну и не надо считать всех бустовцев религиозными фанатиками.
Аргумента "в библиотеке Х это реализовано лучше" вполне хватает, чтобы новую библиотеку не приняли, пока она не будет доведена до качества упомянутой библиотеки Х.
Почитай группу на досуге. Там такие баталии разворачиваются — дай боже.

Или взять, к примеру, multi_index. Библиотека не разрабатывалась для буста, она была совершенно самостоятельной и жила на CodeProject. И когда стало ясно, что лучше на эту тему библиотеки нет — ее включили в буст. (кстати, у тебя есть свой велосипед на эту тему? у меня вот нет и как-то не видно достойных альтернатив)
И ничего, не помешало то, что "ее писали не мы".

E>

---

E>Приношу всем читателям данной темы свои извинения. Тема разрослась слишком сильно, чтобы продолжать ее отслеживать. Поэтому вынужден от нее отписаться. Если кто-то захочет задать мне какой-то вопрос по данной теме -- постараюсь ответить в привате.

И чего? Я в пустоту все это писал, что ли?

You will always get what you always got
  If you always do  what you always did

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

V>Только в частном случае. В общем случае же выигрывает. СИтуация прямо один в один с тем временем когда был переход с С на С++, тоже самое почти .

Ну обычно есть частный случай "практика разработок в компании XXXsoft"

V>...Если, к примеру, я поступлю к вам на работу — изучу кучу ваших велосипедов, а потом как они мне пригодятся?
Ну тебе всё равно много прийдётся изучит специфического для конторы и задачи. Как это тебе пригодиться? Всё-таки STL не так уж много сервисов предлагает. Ну несколько контейнеров. Ну ненужные обычно алгоритмы. Ну запомнишь ты какие у нас контейнеры и как там sort или merge звать. Ну что тут такого сложного?
Да и вообще, если ты пришёл в контору учиться вещам, которые тебе потом пригодятся, а не решать поставленные перед тобой задачи, то, ИМХО, платить должен ты

V>Может ваш программист-идеолог уволиться, придет другой и скажет "другой велосипед!".
Да нет никакого программиста-идеолога. Есть много продуманных решений и большой опыт преемственности и разработок...

E>>Ну а буст -- это вообще эксперементальная, бурно развивающаяся платформа. ИМХО от него зависеть немного страшновато...

V>А ты прям предлогаешь либо вообще без буста, либо ВЕСЬ буст со всеми причиндалами — выжать из него все что только можно. Хотя второй вариант принесет вам дополнительные выгоды. Сказать какие? Прославитесь!

Ну брать библиотеки "по частям", особенно если они нифига не сегментированы на них, или писать свои -- работа, ИМХО, примерно олинаковая. Только во втором случае ты менешь зависишь от неконтролируемых факторов...

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

L>Возьми Symbian-овские котейнеры и потрать минуту.

Прости, не помню что не так с Symbian-кими строками. На худой конец есть просто pure C, если всё так ужасно...
Но я знаю много нормальных вполне строк. Например MFC'шные, или ATL'ные...

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

J>Я бы сказал даже короче: продуманная схема владения объектами рулит
J>А уж на чем ты ее реализовал — пофиг, хоть на голых указателях.
Ну да. Продуманная схема -- ключевой ингридиент

E>>Лично мне, кстати, больше всего нравится такая конструкция:

E>>Вот такая вот замена GC. Дёшево, быстро и сердито. Есть проблемы. Главная -- требуется поддержка такой парадигмы библиотекой, чего от STL добиться нелегко
J>А в чем проблема? В том, что все объекты аллокатора должны быть одинаковыми?
Ну много проблем разных. Главная в том, что STL не имеет никаких средств для манипуляции аллокаторами памяти. Надо тогда везде векторы специально специфицировать, это где-то забудут...

J>...По окончании работы все прибивалось, после чего уничтожался главный контейнер, уже со всем содержимым.
Ну и правильно Примерно то же самое, но другими средствами. Я примерно про это и говорю, что фишка не в STL или не STL, а в том, чтобы прогпть уметь

L>>Возьми Symbian-овские котейнеры и потрать минуту.
E>Прости, не помню что не так с Symbian-кими строками.

Там строки разбиты на две сущности — буфер и именно строка. + константные и неконстантные строки выражаются разными классами. + буфера для строк на стеке и в куче выражаются разными классами. В итоге имеем зоопарк из дюжины классов, в каждом — от десятка до сотни методов. При этом конкатенация двух строк — задача, повергающая новичка в ступор на пол-часа — час.

С контейнерами у них примерно такой же фейеричный дизайн.

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

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

L>Там строки разбиты на две сущности — буфер и именно строка. + константные и неконстантные строки выражаются разными классами. + буфера для строк на стеке и в куче выражаются разными классами. В итоге имеем зоопарк из дюжины классов, в каждом — от десятка до сотни методов. При этом конкатенация двух строк — задача, повергающая новичка в ступор на пол-часа — час.

Скорее всего это зачем-то надо. Типа памятью управляют экономно. А хедер есть где посмотреть?

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

E>Скорее всего это зачем-то надо. Типа памятью управляют экономно. А хедер есть где посмотреть?

Вот статья. Если сильно нужен хедер, скажи — попробую выдрать из SDK
http://newlc.com/Using-Symbian-OS-String.html

E>Анологично. Похоже ты какую-то концепцию этой библиотеки не узнал вовремя...
Да с конецепциями-то всё понятно. Сложность вносит то что дизайн заточен как-то... ну как сказать... странно
К примеру — есть строка в куче, HBufC* str. Так вот, чтобы получить из неё константный указатель (const TDesC&) — надо её разыменовать, типа *str, а вот чтобы получить неконстантный (TDes&) надо вызвать метод Des, вот так вот: str->Des(). Ну и названия классов — краткие, но чтобы привыкнуть их читать приходится потратить определённое время...

Да, сорцы закрыты — в тонких моментах приходится разбираться "методом тыка".