Re[22]: Про boost - Компьютерные священные войны

E>Почему люди считают нужным заявлять "Я использую Boost!", тогда как заявлений "Я использую ACE!" или "Я использую Poco!" не видать? Или использование Boost это как обряд инициации -- все, мол, не девственник я уже, но мужик?

Использование boost — это отличие новичка от профессионала. Студенты еще слабо знакомы с языком, они знают минимум и на большее, чем на изобретение велосипедов из подручных средств не способны (сам был таким). Зрелые разработчики останивились в своем развитии и ничего нового изучать не хотят. Да и зачем им это надо. Дифицит программистов на рынке ух какой! Профессионалам же надо разрабатывать коммерческие системы в сжатые сроки с минимумом ресурсов и у них просто нет времени писать свой велосипед. Boost — это яркий пример библиотеки общего использования, который и дает строительные блоки для современных сложных систем.

E>Мне кажется, что такая точка зрения гораздо приятнее для любителей буста, чем доводы, что Boost -- это:
E>- охринительного размера архив;
У вас все еще диалап? Или Поиск-1? Тогда мы к вам идем

E>- что библиотеки в нем все слеплены вместе. И если нужна одна-единственная библиотека, то нужно вручную вырезать ее из Boost-а через scp (и делать это потом регулярно);
Нафиг надо.
E>- что в дебрях Boost-а полно шаблонов и #if-ов (для преодоления кривости компиляторов) и что нужно иметь большой опыт в C++, чтобы в случае необходимости забраться туда и понять, падает ли программа из-за Boost-а или из-за чего-то еще;
Я легко могу вычленить код для моего компилятора, если вы — нет, то это ваша проблема. К тому же доки никто не отменял.
Более того, в бусте уже пройдены подводные камни, а в ваших велосипедах — нет.
E>- что кроме Boost-а есть другие библиотеки, как общего назначения, так и специализированные. И как следствие, для некоторых вещей из Boost-а можно найти очень достойную альтернативу, которая и меньше, и проще, и обновляется быстрее (например, boost vs pcre для регулярных выражений);
Ну и что? Boost запрещает это использовать?
E>- что часть вещей Boost-а, которые широко используются (например, shared_ptr) уже есть в других библиотеках (например, аналоги shared_ptr есть ACE, в Loki, в Poco). Поэтому, если в проекте уже используется другая большая библиотека (ACE или Poco), то не так уж хочется тянуть в него еще одну еще большую из-за пары рюшечек;
А использовать можно только то, что надо. Boost не требует использовать все классы во всех либах.
E>- что в Boost-е многого нет. Например, средства работы с XML. Тогда как в других фреймворках (Poco, Qt) есть.
Ну так и используйте! Boost вам не мешает.

Что за мания все резать? Вы когда ставите операционку, то удаляете все лишние сервисы, ослика и прочую бесплатную лабуду в придачу? Если не надо, то пусть себе валяется, нафига заморачиватся по пустякам. В бусте все используемые в проекте либы можно отследить по инклудам.

Кстати, CRT и STL — тоже по вашим меркам гигантские библиотеки. Давайте вы их тоже в топку выкините и будете писать прямые инструкции процессору (Привет фанатам ассемблера).

E>У нас принята система, в которой использованные в проектах 3rd-party библиотеки размещаются в репозитории. Это дает возможность извлечь конкретную версию конкретного проекта с теми версиями сторонних библиотек, которые использовались на момент фиксации версии. А когда делаешь checkout какого-нибудь проекта, а он затем начинает тянуть за собой десятки мегабайт архивов, которые затем еще и долго и мучительно компилируются, то начинаешь ценить минимализм зависимостей.

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

.
Хранилище нужно для файлов, которые вы изменяете, а не для сторонних либ, которые вы не трогаете. Вот вам хранилище буста: http://svn.boost.org/svn/boost. Используйте его и не изобретайте велосипед.

А по поводу "минимализма зависимостей": уж поверте, что лучше зависеть от буста, чем от самописной приблуды коллеги без нормальной документации и кучей неявных условностей и багов, которая "упрощает" жизнь давая пару рюшечек в проект. Boost — это мощь, а велосипеды — это жалкая попытка добится этой мощи.

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

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

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

Это, блин, прям смесь фетишизма и эксбиционизма в одном флаконе. Похоже, что boost -- не технический инструмент, а объект религиозного поклонения.

Почему люди считают нужным заявлять "Я использую Boost!", тогда как заявлений "Я использую ACE!" или "Я использую Poco!" не видать? Или использование Boost это как обряд инициации -- все, мол, не девственник я уже, но мужик?

N>В каждой конторе есть гуру, которому все верят

и вот приходит человек горит, эй! давайте boost использовать будем, это ведь так и так и сяк, нам поможет, гуру косо посмотрит, потом одним глазом доку по бусту на искосок просмотрит и скажет... не фигня... тут можно обойтись этим и этим.

Да все еще проще -- гуру, особенно старые, которые начинали двадцать-пятнадцать лет назад, они же C++а-то нормального и не видели. То шаблонов там не было, то исключений, то были но кривые, то компиляторы глючные, то C++ники к ним в команду попадались такие, что проще пристрелить было, чем руки вправить. Багов им пришлось выловить множество из-за "красивого" кода, поэтому понятие прекрасного у них извращенное. Вот и остались они все такие неграмотные-неграмотные, зашоренные-зашоренные. Да еще все высокомерные, мол че вы, молодая милюзга, со своим boost-ом причапилися? Мы без него на перфокартах дырдочки пробивали и сейчас обойдемся.

Мне кажется, что такая точка зрения гораздо приятнее для любителей буста, чем доводы, что Boost -- это:
— охринительного размера архив;
— что библиотеки в нем все слеплены вместе. И если нужна одна-единственная библиотека, то нужно вручную вырезать ее из Boost-а через scp (и делать это потом регулярно);
— что в дебрях Boost-а полно шаблонов и #if-ов (для преодоления кривости компиляторов) и что нужно иметь большой опыт в C++, чтобы в случае необходимости забраться туда и понять, падает ли программа из-за Boost-а или из-за чего-то еще;
— что кроме Boost-а есть другие библиотеки, как общего назначения, так и специализированные. И как следствие, для некоторых вещей из Boost-а можно найти очень достойную альтернативу, которая и меньше, и проще, и обновляется быстрее (например, boost vs pcre для регулярных выражений);
— что часть вещей Boost-а, которые широко используются (например, shared_ptr) уже есть в других библиотеках (например, аналоги shared_ptr есть ACE, в Loki, в Poco). Поэтому, если в проекте уже используется другая большая библиотека (ACE или Poco), то не так уж хочется тянуть в него еще одну еще большую из-за пары рюшечек;
— что в Boost-е многого нет. Например, средства работы с XML. Тогда как в других фреймворках (Poco, Qt) есть.

N>Вот и нет продвижения для такой классной либы.

И поэтому целью жизни должна стать ее популяризация

O>Был в одной конторе в США в командировке (солидненькая канторка). Спросил у них там за Буст, мол используете ли ? Ответ был "а что это такое ??" , спросил еще человека 3-4 тот же вопрос — ответ "а что это такое??". Это говорили дядьки с пожалуй не меньше чем с 10-ти летним опытом работы.

O>По поводу нас: думаю многие не используют Буст просто потому, что он им кажется тяжелым (слабенькие спецы).

Ну например мне он кажется "тяжелым". В прямом смысле. ZIP весит 44 мегабайта, в распакованном виде — больше 100MB.
Делать лишний депенденси на 100 мегабайт — это я так понимаю — профессиональное решение? У меня проект со всеми внешними либами лезет в 5-6 мегабайт и буста в нем не будет.

O>Думаю что чтоб юзать Буст нужен неплохой уровень знания языка и теории (смарт поинтеры , функторы, и т.д. ).

Там столько разного хлама, что диву даешься. Некоторые части Boost написаны квалифицированными профи, некоторые — идиотами.

Boost идеологически похож на PHP. А не забахать ли нам фенечку со свисточком? Пожалуйста — забабахай и включи в либу. Как в PHP создатели идут по пути добавлния в язык встроенных функций, так и буст растет вширь безконтрольно. Разбираться во все этом дерьме?

Вот STL — компактная, стандартизованная, концептуально-чистая и понятная билиотека. Сделал один талантливый человек.

Вот кто мне скажет что такое BOOST? Насколько я понимаю — это Universal Superlibrary в стиле "All Things to All Men". Boost содержит в себе "все", но в каждом конкретном случае как правило можно найти реализацию лучше

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

_>>Использование boost — это отличие новичка от профессионала.
E>Все остальное не вижу смысла комментировать, поскольку ведется противопоставление Boost-а каким-то абстракным самописным велосипедам, о которых я вообще не говорил.

Наблюдал не раз следующий путь становления:

1) Не знает ни о STL ни о Boost
2) Узнает о STL и кидается все писать с максимальным использованием STL везде где ни попадя.
3) Получает кадавров с трехэтажными шаблонами в которых сам часто путается — какой же тут функтор вызывается из этого трехэтажного бинда? Фанатизм начинает остывать.
4) Понимает что STL не панацея и умеренно использует его только там, где надо.
5) Узнает о Boost и повизгивая от восторга кидается применять все что только можно везде где только можно.
6) Получает жутких монстров с еще более запутанной структурой, с regex на каждый чих и компилящихся часами — фанатизм быстро проходит.
7) Понимает что и Boost не идеален и начинает использовать только то, что реально необходимо и только там где надо.
8) Пишет свои алгоритмы, которых нет в STL\Boost либо готовые версии которых не устраивают по каким либо причинам.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

_>Поискал в гугле slexcast, нашёл твой сайт. Всё сразу стало ясно: запущенный случай велосипедостроедизма:
_>args_4 => Boost.Program_options

Библиотеки args_* я развивал и использовал где-то с 1996 до 2004. Boost.Program_options появился в Boost 1.32, это где-то 2004-й год.

_>auto_ptr_3 => Boost.Smart_ptr

auto_ptr_* это попытка устранить косяки с auto_ptr в разных компиляторах (VC++ 5.0, 6.0, g++ 2.95). Где-то в районе 1998-2002 гг.

_>cls_2 => Boost.Program_options

Мимо кассы. Cls -- это синтаксис разметки, основанный на ситаксисе языка программирования Curl. В чем-то конкурент XML и YAML. Первая реализация -- 2001-й год, сейчас идет разработка cls_3. Уже несколько лет есть ее порт на Ruby -- ClsRuby.

_>cpp_util_2 => Boost.Conversion + noncopyable + Function

+ еще адаптация к особенностям разных компиляторов. И все это в нескольких килобайтах архива.
Эксперименты с unary_method -- это так, попытка приобщится к modern C++ design. В будущем я его вообще оттуда выкину.
Новые версии cpp_util_2 я вообще очень давно на сайт не выкладывал, а там появились новые вещи, например, hex_dump::string_dumper, hex_dump::hex_escaped_string_dumper, string_piece, temporary_object_ref.

_>mxx4 => Boost.Build

mxx4 был разработан в начале 2001 года. В 2004 был заменен на Mxx_ru. В некоторых вещах Boost.Build вообще не имеет никаких преимуществ перед инструментами типа Mxx_ru или SCons, если не сказать больше.

Имхо, Boost.Build может нравится только тем, кто нормальных инструментов не видел, т.к. SCons, qmake, Rake, CMake, MPC, Mxx_ru.

_>smart_ref_3 => Boost.Smart_ptr

Первые smart_ref_* у меня появились, если не ошибаюсь, где-то в 97-м. Одна из целей smart_ref_* -- сделать возможным экспорт умных указателей из DLL. Уже года три не используется -- есть ACE_Refcounted_Auto_Ptr.

_>threads_1 => Boost.Thread

Библиотека threads появилась в 96-м, и прошла через Windows, OS/2, Linux, BSD еще до того, как о Boost-е узнала общественность. Затем была адаптирована даже под NonStop Kernel. С 2004 года не используется вообще. Сейчас есть средства ACE.

Кстати, в threads_1 такие вещи, как condition variables и rw_mutex, присутствовали давно и на всех платформах. В отличии от.

Ты еще забыл ObjESSty => Boost.Serialization.

_>Не, тебе своего времени не жалко?

Жалко. Но это не было потерянное время. Сейчас такие вещи, как cls, mxx_ru и objessty -- это ключевые инструменты в наших проектах. А mxx4 был хорошим опытом реализации своего скриптового языка, который затем несколько раз был востребован.

_>Ну ладно было бы что-то чего нет в бусте, или было бы сделано лучше.

ObjESSty -- половины ее функциональности в бусте нет, а вторая половина в бусте просто хуже.
cls -- в бусте нет.

_>Хочется что-то сделать — сделай то, чего ещё нет. Например Boost.DB, Boost.GUI или Boost.Net. Сразу станешь famous.

А я и делаю. ObjESSty, например. Mxx_ru. SObjectizer. За счет чего уже famous в узких кругах.

Делать что-нибудь для Boost? Это неправильная постановка вопроса -- разрабатывать нужно то, что необходимо тебе и, при желании, публиковать в виде OpenSource. Кто заинтересуется -- присоединится к разработке.

Boost.DB => есть OTL, Soci, Qt, Ultimate++
Boost.GUI => есть FLTK, FOX, Qt, wxWidgets, Ultimate++
Boost.Net => есть ACE, Poco

Ну и нафига в очередной раз заводить песню "мы наш мы новый мир построим"?

sc пишет:
>
>
> Ну может реализация там и не простая, но использование большинства
> бустовских библиотек достаточно простое и удобное.

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

Posted via RSDN NNTP Server 2.1 beta

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

...
H>Вот кто мне скажет что такое BOOST? Насколько я понимаю — это Universal Superlibrary в стиле "All Things to All Men". Boost содержит в себе "все", но в каждом конкретном случае как правило можно найти реализацию лучше

Буст — это набор библиотек. И никто не заставляет использовать все. Я использую только те, которые нужны. И помогает мне в этом утилитка bcp. Она умеет "выгрызать" только необходимые библиотечки.
Теперь меняем стереотипы

Universal Superlibrary -> Bundle of simple and sufficient libraries
All Things to All Men -> Take only what you need

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

sc>Теперь меняем стереотипы

sc>Universal Superlibrary -> Bundle of simple and sufficient libraries

Это какая библиотека там simple?

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

CC>Наблюдал не раз следующий путь становления:

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

Другое дело, что говоря о Boost-е надо бы различать две разных вещи:
1. С++ библиотека общего назначения.
2. Движение C++ников по созданию новой стандартной библиотеки для C++ (типа нашего ответа Чемберленам JDK и .NET Framework).

Имхо, вторая составляющая в спорах вокруг Boost-а является доминирующей. И часто сторонники Boost-а занимают позицию "Кто не с нами, тот против нас". Имхо, это не есть хорошо.

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

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

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

E>>>2. Движение C++ников по созданию новой стандартной библиотеки для C++ (типа нашего ответа Чемберленам JDK и .NET Framework).

E>>>Имхо, вторая составляющая в спорах вокруг Boost-а является доминирующей.

KV>>Кстааати, (раз уж выделенное тут прозвучало), в чем преимущества буста перед дотнетом?

E>Боюсь, этот вопрос сродни вопросу о преимуществе бананов перед помидорами.

Но ведь бананы-то длиннее

N>ответ у всех — нет

Был в одной конторе в США в командировке (солидненькая канторка). Спросил у них там за Буст, мол используете ли ? Ответ был "а что это такое ??" , спросил еще человека 3-4 тот же вопрос — ответ "а что это такое??". Это говорили дядьки с пожалуй не меньше чем с 10-ти летним опытом работы.

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

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

Прекрасный ответ.

Добавлю еще, что использование boost в компании (или на проекте) предусматривает общий высокий уровень владения C++. Не несколько гуру (или фанатов), а именно большинство.
Иначе время на разработку только увеличится.

Так что, пока boost не вошел в стандарт, пока не появилась критическая масса программистов (скажем, процентов 80), владеющих boost — использовать boost на проектах не только не выгодно, но и опасно.

Заявления типа:
— там где я, там и boost
— считаю своим долгом первым делом поставить boost
— не представляю себе машины разработчика без boost
являются или фанатичными или следующими моде или просто глупыми.

И почему идет противопоставление — "использовать boost" или "изобретать велосипед" (далее древние шутки про квадратные колеса)?
Другие варианты тоже есть.

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

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

E>>2. Движение C++ников по созданию новой стандартной библиотеки для C++ (типа нашего ответа Чемберленам JDK и .NET Framework).

E>>Имхо, вторая составляющая в спорах вокруг Boost-а является доминирующей.

KV>Кстааати, (раз уж выделенное тут прозвучало), в чем преимущества буста перед дотнетом?

Боюсь, этот вопрос сродни вопросу о преимуществе бананов перед помидорами.

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

I>То есть использование boost отличает новичка от профессионала?

Конечно. Буст — относительно новая штука, его больше новички знают.

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

N>Тут вот ради забавы, спросил некоторых товарищей по разным конторам, boost используете?
N>ответ у всех — нет
N>Немного конфузит.
N>А у других как?
На одном проекте использовали — потом отказались во время оптимизаций и профилирования. Пользовали указатели, пару контейнеров и прочую мелочевку. Заменили на самописные более "легкие" аналоги.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

N>А не используют по контором мне кажется вот по какой причине.
N>В каждой конторе есть гуру, которому все верят

и вот приходит человек горит, эй! давайте boost использовать будем, это ведь так и так и сяк, нам поможет, гуру косо посмотрит, потом одним глазом доку по бусту на искосок просмотрит и скажет... не фигня... тут можно обойтись этим и этим.

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

Я не против Boost, я против его бездумного использования.

sc>Ну может реализация там и не простая, но использование большинства бустовских библиотек достаточно простое и удобное.

— Сложные либы в виде хедеров увеличивают время компилляции, прекомпал хедеры помогают, но не всегда
— Многие либы тянут вереницу зависимостей, что раздувает репозитарий. Я не считаю нормальным выделять 100 мегабайт кода для проекта который может уместиться в 10 Mb с использованием более простых либ
— Да, в Boost тоже есть баги.
— Обновление либ такого объема — еще та радость
— Далеко не все либы в boost хорошего качества

К примеру — я посмотрел регулярные выражения в boost и взял TRE (TRE is a lightweight, robust, and efficient POSIX compliant regexp matching library with some exciting features such as approximate (fuzzy) matching). 400kb без внешних зависимостей и куча платформ.

Взяв 3-4 библиотки которые мне нужны я получил все что мне надо

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

KV>>>Кстааати, (раз уж выделенное тут прозвучало), в чем преимущества буста перед дотнетом?

E>>Боюсь, этот вопрос сродни вопросу о преимуществе бананов перед помидорами.

KV>Тогда как оно может являться ответом управляемому Чемберлену?

Неоспоримое достоинство JDK и .NET Framework для многих разработчиков состоит в том, что они являются большими стандартными библиотеками, в которых есть очень и очень много всего. Стандартная библиотека C++ по сравнению с ними -- это просто бедный родственник. Даже для поддержки многопоточности или hash-таблиц C++никам сейчас нужно использовать сторонние, а значит нестандартные, библиотеки.

Поэтому очень и очень многие C++ники, включая самого Страуструпа, мечтают о тех светлых днях, когда у C++а будет большая и хорошая стандартная библиотека. И Boost-оводы пытаются ее воплотить посредством своего детища.

Ну теперь я сам себе отвечу

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

А не используют по контором мне кажется вот по какой причине.
В каждой конторе есть гуру, которому все верят

и вот приходит человек горит, эй! давайте boost использовать будем, это ведь так и так и сяк, нам поможет, гуру косо посмотрит, потом одним глазом доку по бусту на искосок просмотрит и скажет... не фигня... тут можно обойтись этим и этим.

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

... Вот и нет продвижения для такой классной либы.

sc>Буст — это набор библиотек. И никто не заставляет использовать все. Я использую только те, которые нужны. И помогает мне в этом утилитка bcp. Она умеет "выгрызать" только необходимые библиотечки.
sc>Теперь меняем стереотипы

sc>Universal Superlibrary -> Bundle of simple and sufficient libraries

Простые либы и Boost — это две большие разницы. Некоторые либы в бусте — просто монстры по сложности

sc>All Things to All Men -> Take only what you need

Возьми одну либу — подключи двадцать либ от которых она зависит.

Точно и образно подмечено.
У некоторых — прямо таки поклонение Boost.
Прям объект религиозного культа.

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

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

H>Некоторые библиотеки буст — редкостное дерьмо.
Пример можно? Насколько я понимаю, Вы настолько круты, что одной левой напишете лучше? И это будет работать на десятке компиляторов? Вас как зовут? Саттер или Мейерс?

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

E>Понятно, т.е. вместо кода:
E>

E>int result = do_something();
E>if( result )
E>  throw some_exception( "do_something failed with result: " + slexcast( result, hex_0x ) );
E>

E>мне нужно будет делать что-то вроде:
E>

E>int result = do_something();
E>if( result )
E>  throw some_exception( "do_something failed with result: " + str( format( "0x%x" ) % result ) );
E>

E>Зато, блин, буст. Не какой-нибудь свой велосипед.

Поискал в гугле slexcast, нашёл твой сайт. Всё сразу стало ясно: запущенный случай велосипедостроедизма:
args_4 => Boost.Program_options
auto_ptr_3 => Boost.Smart_ptr
cls_2 => Boost.Program_options
cpp_util_2 => Boost.Conversion + noncopyable + Function
mxx4 => Boost.Build
smart_ref_3 => Boost.Smart_ptr
threads_1 => Boost.Thread

Не, тебе своего времени не жалко? Ну ладно было бы что-то чего нет в бусте, или было бы сделано лучше. Так у тебя ж даже тестов нормальных нет и функциональности десятая часть от бустовских аналогов. Хочется что-то сделать — сделай то, чего ещё нет. Например Boost.DB, Boost.GUI или Boost.Net. Сразу станешь famous.

Здравствуйте, Дм.Григорьев, Вы писали:

E>>В нем все есть

ДГ>Выходит, он нарушает single responsibility principle?

Boost -- это не библиотека, а набор библиотек, собранных под одной крышей. Эдакая сборная солянка различных вещей, выполненных, однако, в традициях modern C++ overdesign

(шучу, но только от части).
Задача Boost-а в том, чтобы быть полигоном для разработки библиотек, которые могут быть включены в следующие версии стандартных библиотек C++. Первые плоды этой работы уже видны в TR1, который станет частью будущего стандарта C++0x.

Отличие Boost-а от таких библиотек, как ACE, Poco, Qt или wxWidgets состоит в том, что прием новых библиотек в Boost осуществляется на основании откликов пользователей на новые библиотеки. Т.е. некий Вася Пупкин решил, что его библиотека достойна принятия в Boost, оформил ее в соответствии с требованиями Boost-а, сообщил о ней Boost-оводам, те сделали предварительную оценку, потом вывели на публичное обсуждение. Набрала библиотека достаточное количество голосов -- попала в Boost. Насколько она будет нужна конечным пользователям -- это отдельный вопрос и я не знаю, как он учитывается при приеме новых библиотек в Boost.

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

O>По поводу нас: думаю многие не используют Буст просто потому, что он им кажется тяжелым (слабенькие спецы).

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

N> Вот и нет продвижения для такой классной либы.

Только вот без фанатизма пожалуйста

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

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

А не получается ли то что вы СВОИ технические проблемы переностите на библиотеку ?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

_>Использование boost — это отличие новичка от профессионала.

Пять балов!

Все остальное не вижу смысла комментировать, поскольку ведется противопоставление Boost-а каким-то абстракным самописным велосипедам, о которых я вообще не говорил.

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

E>Поддаются версионному контролю. А иногда даже приходится править ошибки самому и хранить исправленную версию до очередного релиза библиотеки.
А почему бы этот багфикс сразу в буст не закоммитить?

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

RO>>по-моему, есть смысл поискать в первую очередь в Boost, а потом уже и в других местах.

E>Подобный подход и есть свидетельство религиозного ослепления. Искать нужно сразу несколько альтернативных библиотек и сравнивать их достоинства и недостатки более-менее объективно. И только при прочих равных вариант из Boost-а может для кого-то быть предпочтительным именно из-за Boost-а.

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

RO>Библиотеки Boost хорошо документированы, хорошо поддерживаются, единообразны, с простой лицензией. Если в Boost есть что-нибудь, что подходит по всем параметрам, зачем искать дальше?

Это мантра-заклинание?
Некоторые библиотеки буст — редкостное дерьмо.
Затем что часто есть на порядок более простые и качественные решения

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

vsb>>Как ни крути, я считаю, что система контроля версий нужна только для контроля версий.

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

Тут на форуме длинные ветки по поводу STL есть , а вы буст буст ...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E>2. Движение C++ников по созданию новой стандартной библиотеки для C++ (типа нашего ответа Чемберленам JDK и .NET Framework).

E>Имхо, вторая составляющая в спорах вокруг Boost-а является доминирующей.

Кстааати, (раз уж выделенное тут прозвучало), в чем преимущества буста перед дотнетом?

H>>>>Некоторые библиотеки буст — редкостное дерьмо.
_>>>Пример можно? Насколько я понимаю, Вы настолько круты, что одной левой напишете лучше? И это будет работать на десятке компиляторов? Вас как зовут? Саттер или Мейерс?

M>>В этой ветке уже четыре раза прозвучало еvs. Boost::Regex
M>>Тут уже говорилось про XML
_>И при чём здесь XML? Товарищ выдвинул утверждение -- "Некоторые библиотеки буст — редкостное дерьмо.". XML в бусте нет. Как несуществующая библиотека может быть дерьмом?
_>А TRE рядом с творением Мэддока даже рядом не стояло.

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

ЗЫ. Если XML'я в бусте нет, и я уже использую библиотеку, в которой он есть, и которая предоставляет аналоги из буста, зачем мне буст?

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

M>>>ЗЫ. Если XML'я в бусте нет, и я уже использую библиотеку, в которой он есть, и которая предоставляет аналоги из буста, зачем мне буст?

_>>Вам -- незачем. Можете даже писать на голом компиляторе, используя исключительно функции операционки. Всё остальное -- от лукавого.

M>Блин. Почему такие крайности? Почему или обязательно буст или голый компилятор или кривые велосипеды? Почему не тот же loki?

Дима, ну ты прям как маленький! Другие библиотеки ведь искать нужно, сравнивать, выбирать. А Boost -- вот он, готовенький, все про него знают. В нем все есть, а чего сейчас нет, то когда-нибудь будет, а сейчас оно и не надо. Берешь и пользуешься, короче говоря. Да и еще и осознаешь себя продвинутым C++ником: как же, я же Boost знаю, использую его, помогаю делать новую стандартную библиотеку для C++.

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

E>В нем все есть

Выходит, он нарушает single responsibility principle?

Disclaimer: буста не знаю, но нельзя же оставаться в стороне от такого продвинутого обсуждения.

RSDN@Home 1.1.4 stable SR1 rev. 568

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

M>Именно так. Порог вхождения в буст может быть намного меньше , как и попрог вхождения в STL , именно потому что буст довольно известная библиотека.

Ну да. Только тут сочетается два принципа, которые приводят меня в бешенство: "Есть только один правильный способ делать вещи" и "Кто не с нами, тот против нас".

Вот например. Boost.Serialization или Boost.Regex не единственные библиотеки подобного рода для C++. Наверняка в какой-то области они для кого-то лучше других, а в какой-то хуже. Тем не менее, они обе находятся в более выигрышном положении по отношении к другим подобным библиотекам. Если пользователи выбирают их только потому, что они есть в Boost-е, а пользователь уже знаком с Boost-ом, то, в конечном счете, пользователи обкрадывают самих себя, лишая себя возможности использования более достойной альтернативы (в каких-то условиях).

В конце-концов, это обычное дело в области продуктов массового потребления (95% потребителей, по заверениям Генри Форда, готовы брать то, что им предлагают, если это достаточного хорошего качества и по приемлимой цене). Но, когда речь идет о инструментарии для разработки ПО нужно понимать, что любая библиотека имеет недостатки. Будь то Boost или STL. И могут быть условия, при которых лучше отказаться от мейнстримовых инструментов в пользу чего-то экзотического. Однако, когда я вижу фанатичное доказывание, что Boost -- наше все, мне кажется, что такого понимания возникнуть не может.

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

E>Отличие Boost-а от таких библиотек, как ACE, Poco, Qt или wxWidgets состоит в том, что прием новых библиотек в Boost осуществляется на основании откликов пользователей на новые библиотеки.

Да я в общем-то чиста пошутить пытался. Но за вот эту разжёванную инфу спасибо, подробностей про Васю Пупкина я не знал.

RSDN@Home 1.1.4 stable SR1 rev. 568

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

E>>Все это наводит на мысль, что у некоторого количества людей складывается стереотип "Boost -- это хорошо и правильно. А вот не Boost -- это слабенькие спецы/старые пердуны и пр."

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

А вот пусть не наводит. Почему предположить, что программист не использует стандартную библиотеку C++ по объективным причинам сложнее, чем предположить, что это недоучка или старый пердун?

Вот, например, если кто-то предпочитает использовать функции open/read/write/lseek вместо std::fstream -- это показатель непрофессионализма? А если кто-то не использует std::map из-за высоких накладных расходов последнего -- это что?

M>А если кричит что буст это отстой и при этом не строчки не зная и не понимая как это работает тогда да, это старые пердуны.

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

E>>Ну кому-то же нужно повторять "Карфаген должен быть разрушен!". А то очень удобно считать, что Boost это классная и полезная штука.

M>А я именно так и считаю, что "Boost это классная и полезная штука." и мне это очень удобно.

Ну и хорошо. Но это не объясняет, почему пользователи Boost-а с таким апломбом зявляют "Я использую Boost". Вот ты можешь объяснить?

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

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

Ты сейчас говоришь о недостатках в реализации каких-то библиотек. Я же говорю о недостатках Boost как некоего движения разработчиков. Одна большая "правильная" библиотека -- это то, что я не хочу видеть как будущее для C++.

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

E>>Вот, например, если кто-то предпочитает использовать функции open/read/write/lseek вместо std::fstream -- это показатель непрофессионализма? А если кто-то не использует std::map из-за высоких накладных расходов последнего -- это что?
_>Ага. А взамен такой товарищ будет юзать самописный список с линейным поиском.

Если человек может объяснить, почему std::map в его ситуации не подходит и какие именно накладные расходы ему мешают, то он вряд ли будет делать список с линейным поиском. Хотя, в некоторых случаях, линейный поиск по короткому вектору будет намного быстрее поиска в std::map-е.

_>Плавали, знаем.

Понятно. Попробуй устроится в контору с нормальным уровнем разработки на C++.

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

_>>А вот один противник тут крикнул -- "Некоторые либы в бусте — дерьмо!", но на конкретную просьбу назвать оные скромно удалился.

E>Ну я одну такую могу назвать: lexical_cast. Тормозная и ресурсоемкая штука. К тому же негибкая.

Её тормознутость как раз от гибкости-то и происходит! Ибо она учтёт при конвертировании все пожелания твоей локали. Это надо понимать, решая, юзать её, или что-то другое. Впрочем в 90% случаев её скорости вполне достаточно. А если у тебя формат жёстко задан -- ясен пень, что специализированный парсер её обгонит. Короче, опять же слабое понимание возможностей и потребностей.

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

E>>Понятно. Попробуй устроится в контору с нормальным уровнем разработки на C++.

_>Спасибо, я уж как-нибудь дальше фрилансером. И денег в три раза больше, и свободы.

Как, тебе хватает $100 в месяц?

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

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

E>>>Понятно. Попробуй устроится в контору с нормальным уровнем разработки на C++.

_>>Спасибо, я уж как-нибудь дальше фрилансером. И денег в три раза больше, и свободы.

E>Как, тебе хватает $100 в месяц?

Мне хватает 70 евро в час.

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

E>>Если она такая гибкая, то как в вызове:
E>>

E>>lexical_cast<std::string>(2048u)
E>>

E>>получить шестнадцатиричное число с префиксом 0x?

_>Тебе не кажется, что ты путаешь божий дар с яичницей? lexical_cast предназначен для простого преобразования из одного типа в другой.

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

_> То, что ты хочешь, это — форматирование. Смотри boost::format например.

Понятно, т.е. вместо кода:

int result = do_something();
if( result )
  throw some_exception( "do_something failed with result: " + slexcast( result, hex_0x ) );

мне нужно будет делать что-то вроде:

int result = do_something();
if( result )
  throw some_exception( "do_something failed with result: " +
    (format( "0x%x" ) % result).str() );

Зато, блин, буст. Не какой-нибудь свой велосипед.

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

И за 11-12 лет ты к своим либом даже юнит-тесты не собрался прикрутить? Короче, говорить тут не о чём. Велосипед -- он и есть велосипед. А то, что велосипеды используются дальше, когда появились production quality аналоги -- это уже клиника.
Да, вот ты сказал, что boost::lexical_cast это плохо, ибо тормозит и негибко. И что slexcast это круто. Ну что ж, смотрим в код, и видим:

template< class From, class Putter >
std::string
slexcast(
    //! Что преобразуется.
    const From & f,
    //! Как преобразуется.
    const Putter & putter )
{
    std::stringstream    ss;
    putter( ss, f );

    return ss.str();
}

и ты хочешь сказать, что это быстрее чем boost::lexical_cast или гибче чем boost::format?

Комментарии нужны, или и так всем всё ясно?

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

M>В данном случае я бы дал оценку , что использование сторонней библиотеки "Qt, MFC, wxWidgets" не дает преимуществ которые бы компенсировали падение сопровождаемости.

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

Более того, лично на придерживаюсь противоположной точки зрения. Скажем, при разработке GUI приложения использование только Qt-шных средств (включая строки и контейнеры) упростит приложение, т.к. средства Qt изначально увязаны друг с другом, а поддержка STL в Qt является опциональной. Для примера можно взять одновременное использование std::string и QString: необходимость преобразования данных между типами, что выливается в лишний (по сути, мусорный) код и снижение производительности.

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

E>>Boost.Regex vs PCRE vs Greta vs TRE vs POSIX
E>>Boost.Serialization vs s11n.net
E>>Boost.Random vs Agner Random Library
E>>Boost.SmartPtr vs ACE vs Qt vs Loki vs STLSoft vs Poco vs еще много чего.
E>>Boost.Filesystem vs ACE vs STLSoft vs Qt vs wxWidgets vs Poco vs еще много чего.
E>>Boost.Interprocess vs ACE vs Qt vs Poco
E>>Boost.Asio vs ACE vs Qt vs Poco

E>>(disclaimer: в возможностях каких-то библиотек я могу ошибаться).

M>Насколько я помню , к примеру , ACE достоаточно серьезно рассматривался как кандидат в буст. Почему его не включили а начали писать Boost.Asio(мегасырой продукт) я не знаю. Уверен что причины были и их можно найти в мейл листе.

Удивлен тем, что были вообще какие-то планы по включению ACE в Boost. Имхо, это два совершенно разных мира со своими целями и подходами к разработке, у них даже системы сборки принципиально отличаются. Примечательна ремарка товарища, который делал презентацию ASIO на BoostConf'07:

BoostCon, Day 3
...and hear this gem from Jeff as he compares ASIO to the popular ACE library: “ACE is an open source project, so you’re free to download it, look at the source code, and be horrified.”

Вряд ли boost-оводам будет интересно использовать ACE. Зато вот что их явно возбуждает (цитата оттуда же):

The morning ends with a flurry of excitement from the audience about building a library of network protocols on top of ASIO and Boost.Spirit, an effort apparently already underway.

Да ладно, фиг с ним, с ACE. У многих существуют достаточно обоснованные претензии к качеству реализации ACE. Но вот что по поводу других альтернатив библиотекам Boost-а, которые были упомянуты мной выше?

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

Использовалась. Потом отказались. Ибо тормоза. Сначала профайлер показал, что прога умирает в boost::any, после замены на boost:variant стало полегче, а с велосипедом (типа COleVariant) всё просто залетало.

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

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

L>>>О каком результате речь? Разве японцы хоть сколь-нибуть заметны в IT?

I>>Ruby

L>И все?

А как же CD-ROM? Это такой вклад в IT, что Ruby с ним и рядом не валялся.

Тут вот ради забавы, спросил некоторых товарищей по разным конторам, boost используете?
ответ у всех — нет
Немного конфузит.
А у других как?

06.08.08 13:18: Перенесено модератором из 'О работе' — Хитрик Денис

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

N>Тут вот ради забавы, спросил некоторых товарищей по разным конторам, boost используете?
N>ответ у всех — нет
N>Немного конфузит.
N>А у других как?

Используем. Легкие вещи (только шаблоны в хидерах) везде, тяжелые (требующие отдельной компиляции бустовских либ) в своих внутренних тулзах.

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

N>Тут вот ради забавы, спросил некоторых товарищей по разным конторам, boost используете?
N>ответ у всех — нет
N>Немного конфузит.
N>А у других как?

Контора большая. За все отделы сказать не могу, но наш использует.
В основном Смартпоинтры, optional, bind, function и type_traits.
Иногда algorithm. И немного MPL =)

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

N>Тут вот ради забавы, спросил некоторых товарищей по разным конторам, boost используете?

Чем заниматься ерундой, лучше драфт Стандарта почитай

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

N>Тут вот ради забавы, спросил некоторых товарищей по разным конторам, boost используете?
N>ответ у всех — нет

Из 4-х мест работы использовался только в одной конторе — и то легкие вещи типа lexical_cast, bind, shared_ptr, в некоторых внутренних библиотеках использовался, кажется, tuple, но у меня не было времени вникать в его использование.

nen777w пишет:
>
> Тут вот ради забавы, спросил некоторых товарищей по разным конторам,
> boost используете?
> ответ у всех — нет
Ничего удивительно. Уровень программистов такой. Во многих конторах и к
STL до сих пор предубеждение. Зато очень любят голые указатели.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, nen777w

Не используем.
В нескольких старых проектах остались unit-тесты, созданные с помощью Boost.UnitTest -- нет желания и времени выкидывать оттуда Boost.

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

N>Тут вот ради забавы, спросил некоторых товарищей по разным конторам, boost используете?
N>ответ у всех — нет
N>Немного конфузит.
N>А у других как?

На нашем проекте используем. Лично мне не приходилось, но что это такое и для чего — понятие имею.

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

N>>ответ у всех — нет

O>Был в одной конторе в США в командировке (солидненькая канторка). Спросил у них там за Буст, мол используете ли ? Ответ был "а что это такое ??" , спросил еще человека 3-4 тот же вопрос — ответ "а что это такое??". Это говорили дядьки с пожалуй не меньше чем с 10-ти летним опытом работы.

Ага. Очень часто программисты запираются в своих маленьких областях и знать не знают,
что происходит вокруг. С такими людьми трудно общаться — часто приходится расшифровывать
через слово. Но при этом они могут быть "спецами" с 10 годами опыта за спиной.

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

N>Тут вот ради забавы, спросил некоторых товарищей по разным конторам, boost используете?
N>ответ у всех — нет
N>Немного конфузит.
N>А у других как?

Стало любопытно, а если спросить: а вы С++ используете? — многие ли ответят утвердительно?

Мне, например, в этом году еще не приходилось писать на срр (за исключением правки мелких багов в старом проекте).

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

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

sc>>Теперь меняем стереотипы

sc>>Universal Superlibrary -> Bundle of simple and sufficient libraries

E>Это какая библиотека там simple?
К примеру, algorithm/string. Есть ещё optional, any, ...

Здравствуйте, nen777w, Вы писали:
N>А у других как?
Я использую слегка, главным образом, чтобы посмотреть как умные люди решают определенные проблемы. А так нет, да и специфика работы не особо предполагает.

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

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

sc>>Теперь меняем стереотипы

sc>>Universal Superlibrary -> Bundle of simple and sufficient libraries

E>Это какая библиотека там simple?

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

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

H>И грамотно сформулированы за и против, очень убедительно и лаконично

Так блин, я же на boost смотрю года с 2002-го, если не с 2001. Несколько раз раньше мы всерьез обсуждали вопрос использования boost-а у себя, даже Boost.UnitTest использовали где-то в 2004-2005 гг. Вначале останавливало неважное качество документации и отсутствие на платформах, которые тогда нам нужны были. А потом как-то привыкли к другим фреймворками/библиотекам и надобности особой в Boost-е просто не возникает.

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

sc>>Буст — это набор библиотек. И никто не заставляет использовать все. Я использую только те, которые нужны. И помогает мне в этом утилитка bcp. Она умеет "выгрызать" только необходимые библиотечки.
sc>>Теперь меняем стереотипы

sc>>Universal Superlibrary -> Bundle of simple and sufficient libraries

H>Простые либы и Boost — это две большие разницы. Некоторые либы в бусте — просто монстры по сложности
Это они внутри, а снаружи белые и пушистые

Никто ведь не заставляет лезть внутрь. По аналогии с автомобилем. Раньше они были простые. Не едет, открыл капот, поковырялся и поехал. Сейчас только звонок в автосервис и на эвакуатор. Хрен там внутри разберешься. И тем не менее все предпочитают современные авто, а не москвич 412.

sc>>All Things to All Men -> Take only what you need

H>Возьми одну либу — подключи двадцать либ от которых она зависит.
Ну и ладно. Взял я, например, смарт-пойнтеры и байнды, для начала, вытащил bcp-шкой в отдельный каталог и юзаю их на здоровье. И мне все равно, сколько там еще подцепилось, 10 или 20 хедеров.
Ну в принципе любое мнение имеет право на существование, и если для кого-то критично кол-во хэдеров, то тогда буст ему не подходит.
(пытаюсь не дать разгореться пламени флейма и дыма оффтопика

)

nen777w пишет:
>
> А не используют по контором мне кажется вот по какой причине.
> В каждой конторе есть гуру, которому все верят и вот приходит человек
> горит, эй! давайте boost использовать будем, это ведь так и так и сяк,
> нам поможет, гуру косо посмотрит, потом одним глазом доку по бусту на
> искосок просмотрит и скажет... не фигня... тут можно обойтись этим и этим.
А бывает и наоборот.

Posted via RSDN NNTP Server 2.1 beta

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

E>- охринительного размера архив;
E>- что библиотеки в нем все слеплены вместе. И если нужна одна-единственная библиотека, то нужно вручную вырезать ее из Boost-а через scp (и делать это потом регулярно);

Почему это вас так волнует? Я рассматриваю буст как обязательную часть оснащения машины С++-разработчика, и при нынешних размерах жесткого диска и толщины каналов в интернет -- в чём тут вообще проблема? Вы же поди не плачете из-за того, что студия занимает на диске 2-3 гига?

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

E>>- охринительного размера архив;
E>>- что библиотеки в нем все слеплены вместе. И если нужна одна-единственная библиотека, то нужно вручную вырезать ее из Boost-а через scp (и делать это потом регулярно);

_>Почему это вас так волнует? Я рассматриваю буст как обязательную часть оснащения машины С++-разработчика, и при нынешних размерах жесткого диска и толщины каналов в интернет -- в чём тут вообще проблема? Вы же поди не плачете из-за того, что студия занимает на диске 2-3 гига?

У нас принята система, в которой использованные в проектах 3rd-party библиотеки размещаются в репозитории. Это дает возможность извлечь конкретную версию конкретного проекта с теми версиями сторонних библиотек, которые использовались на момент фиксации версии. А когда делаешь checkout какого-нибудь проекта, а он затем начинает тянуть за собой десятки мегабайт архивов, которые затем еще и долго и мучительно компилируются, то начинаешь ценить минимализм зависимостей.

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

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

H>Ну например мне он кажется "тяжелым". В прямом смысле. ZIP весит 44 мегабайта, в распакованном виде — больше 100MB.
H>Делать лишний депенденси на 100 мегабайт — это я так понимаю — профессиональное решение? У меня проект со всеми внешними либами лезет в 5-6 мегабайт и буста в нем не будет.

~ :) du -c /usr/lib/libboost_*-gcc41{,-mt}-1_34_1.* | tail -n 1
24382   total

Не топикстартер виноват, что в MS Windows это же занимает 621638 КБ, используйте правильные ОС.

А тем более в архивах:

for pkg in $(apt-cache search libboost | awk '{ print $1; }')
do
    echo "[tr][td]$(apt-cache show $pkg | egrep '^Size:' | head -n 1 | awk '{ print $2; }')[/td][td]${pkg}[/td][/tr]"
done

Размер, байт	Пакет
46121532	libboost-dbg
1932116	libboost-dev
9268976	libboost-doc
368768	libboost-python-dev
199602	libboost-python1.34.1
182014	libboost-date-time-dev
56790	libboost-date-time1.34.1
80496	libboost-filesystem-dev
55748	libboost-filesystem1.34.1
508518	libboost-graph-dev
252322	libboost-graph1.34.1
128294	libboost-iostreams-dev
45066	libboost-iostreams1.34.1
271540	libboost-program-options-dev
190290	libboost-program-options1.34.1
1062616	libboost-regex-dev
550924	libboost-regex1.34.1
622362	libboost-serialization-dev
415554	libboost-serialization1.34.1
87640	libboost-signals-dev
69724	libboost-signals1.34.1
455970	libboost-test-dev
235016	libboost-test1.34.1
46036	libboost-thread-dev
37000	libboost-thread1.34.1
829808	libboost-wave-dev
468098	libboost-wave1.34.1

Кто здесь самый большой? Boost.Regex. Т. е., поставил в зависимость libboost-regex, менеджеру пакетов клиента придется (о ужас!) загрузить полмегабайта пакета с библиотеками.

В MS Windows, кстати, можно переполовинить библиотеки Boost, заменив копии на симлинки (если они есть в вашей любимой ФС, конечно). Остальной размер, наверное, происходит из-за статической линковки чего-нибудь.

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

O>По поводу нас: думаю многие не используют Буст просто потому, что он им кажется тяжелым (слабенькие спецы). Думаю что чтоб юзать Буст нужен неплохой уровень знания языка и теории (смарт поинтеры , функторы, и т.д. ).

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

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

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

O>>По поводу нас: думаю многие не используют Буст просто потому, что он им кажется тяжелым (слабенькие спецы). Думаю что чтоб юзать Буст нужен неплохой уровень знания языка и теории (смарт поинтеры , функторы, и т.д. ).

Z>Многие не используют Буст потому что они понимают, что чтоб юзать Буст нужен очень неплохой уровень знания языки и теории у всех программистов в компании, что очень редко достижимо. Нафиг-нафиг.
Для чего? Чтобы lexical_cast или shared_ptr заюзать?

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

_>Хранилище нужно для файлов, которые вы изменяете, а не для сторонних либ, которые вы не трогаете. Вот вам хранилище буста: http://svn.boost.org/svn/boost. Используйте его и не изобретайте велосипед.
Именно!

А вот здесь http://svn.boost.org/svn/boost/tags/release лежат все версии.

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

E>>У нас принята система, в которой использованные в проектах 3rd-party библиотеки размещаются в репозитории. Это дает возможность извлечь конкретную версию конкретного проекта с теми версиями сторонних библиотек, которые использовались на момент фиксации версии. А когда делаешь checkout какого-нибудь проекта, а он затем начинает тянуть за собой десятки мегабайт архивов, которые затем еще и долго и мучительно компилируются, то начинаешь ценить минимализм зависимостей.

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

Как раз хорошая ссылка о невозможном:

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

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

_>При необходимости есть в интернете репозитории с необходимыми версиями. Для размещения либ достаточно файлового сервера, на котором с исходиниками можно и разместить откомпилированные lib файлы. А превращать хранилище исходных кодов в файловую помойку не вижу смысла.

Не вижу смысла делать какие-то инструменты для закачки tar.bz2 или других архивов из Интернета, или взятия файлов с файл-сервера, когда можно использовать механизм svn:externals:

ace_lib_distrib http://***/svn/ace/tags/distribs/5.6.5/ace_lib_distrib
oracle_oci      http://***/svn/otl_4/tags/oracle.instantclient-10.2.0.4.0
otl4            http://***/svn/otl_4/tags/4.0.173/dev/otl4
pcre            http://***/svn/regex/pcre/tags/mxx_ru/7.7/dev/pcre

_>Тогда уже туда надо запихнуть образы тестовых серверов на момент тестирования, базы данных от заказчиков с багами и кучу всякого мусора

.

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

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

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

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

E>>Поддаются версионному контролю. А иногда даже приходится править ошибки самому и хранить исправленную версию до очередного релиза библиотеки.
_>А почему бы этот багфикс сразу в буст не закоммитить?

Ё! Опять буст! И вне буста есть жизнь.

Есть библиотеки, которые распространяются в виде архивов (pcre, otl) у которых вообще нет публичных репозиториев. Единственный способ внесения изменений в них -- это оформление баг-репорта или передача патча разработчику. Есть библиотеки, у которых есть репозитории (ace), но доступ на запись в него имеет очень ограниченное количество commit-еров. В таких случаях опять же еднственным способом для обычного пользователя является баг-репорт с добавленным в него патчем.

skeptik_ пишет:
>
> Z>Многие не используют Буст потому что они понимают, /что чтоб юзать
> Буст нужен очень неплохой уровень знания языки и теории/ *у всех
> программистов в компании*, что очень редко достижимо. Нафиг-нафиг.
> Для чего? Чтобы lexical_cast или shared_ptr заюзать?
Удивлен? Но да.

Posted via RSDN NNTP Server 2.1 beta

eao197 пишет:
>
> _>А почему бы этот багфикс сразу в буст не закоммитить?
>
> Ё! Опять буст! И вне буста есть жизнь.
>
> Есть библиотеки, которые распространяются в виде архивов (pcre, otl) у
> которых вообще нет публичных репозиториев. Единственный способ внесения
> изменений в них -- это оформление баг-репорта или передача патча
> разработчику. Есть библиотеки, у которых есть репозитории (ace), но
> доступ на запись в него имеет очень ограниченное количество commit-еров.
> В таких случаях опять же еднственным способом для обычного пользователя
> является баг-репорт с добавленным в него патчем.
Т.е. вы сами себе придумываете проблемы, а потом долго и (без)успешно с
ними боретесь?
Мне кажется, что твое отношение к бусту сродни тому, какое отношение у
тупоконечнеков было к яйцу.

Posted via RSDN NNTP Server 2.1 beta

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

E>Не вижу смысла делать какие-то инструменты для закачки tar.bz2 или других архивов из Интернета, или взятия файлов с файл-сервера, когда можно использовать механизм svn:externals:

Не все используют SVN для разработки, и не все библиотеки используют SVN для разработки.

E>Это вовсе не повод бросаться использовать Boost сейчас. Особенно, если уже давно были найдены альтернативы Boost-овским библиотекам.

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

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

Посмотрел boost regex и в ужасе перешел на TRE.

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

N>Тут вот ради забавы, спросил некоторых товарищей по разным конторам, boost используете?
N>ответ у всех — нет

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

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

E>>Не вижу смысла делать какие-то инструменты для закачки tar.bz2 или других архивов из Интернета, или взятия файлов с файл-сервера, когда можно использовать механизм svn:externals:

RO>Не все используют SVN для разработки,

Я всего лишь рассказываю о том, что используется у нас. И о том, почему 3rd-party библиотеки у нас лежат в репозиториях.

RO>и не все библиотеки используют SVN для разработки.

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

E>>Это вовсе не повод бросаться использовать Boost сейчас. Особенно, если уже давно были найдены альтернативы Boost-овским библиотекам.

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

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

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

V>Мне кажется, что твое отношение к бусту сродни тому, какое отношение у
V>тупоконечнеков было к яйцу.

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

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

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

E>У нас принята система, в которой использованные в проектах 3rd-party библиотеки размещаются в репозитории. Это дает возможность извлечь конкретную версию конкретного проекта с теми версиями сторонних библиотек, которые использовались на момент фиксации версии. А когда делаешь checkout какого-нибудь проекта, а он затем начинает тянуть за собой десятки мегабайт архивов, которые затем еще и долго и мучительно компилируются, то начинаешь ценить минимализм зависимостей.

Почему бы просто не держать актуальный HOWTO Prepare Build Environment в проекте или в вики? Вроде ничего сложного нет, скачайте буст с 192.168.1.1/files/boost-1.34.tar.bz2, распакуйте, добавьте в environment variable INCLUDE (или что то подобное) и всё. У тех, кто с проектом работает, всё давно настроено, те, кто пришёл недавно, потратят некоторое время, но это ведь происходит достаточно редко. Если надо пропатчить — держать .patch-файлы где-нибудь, патч это одна команда. Можно даже скрипты написать, если сильно хочется автоматизировать. Как ни крути, я считаю, что система контроля версий нужна только для контроля версий.

А смысла выдирать куски из буста я вообще не понимаю. Он же компилируется именно теми кусками, которые используются в проекте, ни больше ни меньше.

Кстати я не знаю, для С++ нет аналога maven? Там эти проблемы как раз неплохо решены.

vsb>А смысла выдирать куски из буста я вообще не понимаю. Он же компилируется именно теми кусками, которые используются в проекте, ни больше ни меньше.

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

У меня папка Work занимает примерно пять гигов — в разных проектах разные версии бустов, вхворков, кути и прочих монстроидальных либ. Причем часто приложение — тупое окошко и два диалога на одной платформе. Появление очередной мелкой китайской утилиты с очередной версией буста меня совсем не радует.

Буст уродлив прежде всего своей монолитностью. Проще скопировать 100Mb кода чем разбираться в зависимостях

smart pointers, regex, function, bind, crc, tuple мож еще че-то

А вообще, зависит от конторы и людей.
Мне было просто добавить использование boost в проект, на котором работает несколько человек. Инертность команды нулевая. Посмотрели, во, классная штука, которая способна нам помочь. Давай использовать. Но в крупных проектах на это может накладывать отпечаток инерционность, как проекта (что реже) так и команды (это чаще).

Недавно столкнулся с забугорной конторой, которая начала около года назад новый проект, так вот, вся бизнес-логика там на С, и никто не собирается на С++ переходить, не говоря уже за boost. Причем, самое интересное, что контора занимается коммуникациями, именно тем, чем занимается AT&T, т.е. той категорией проектов, ради которых разрабатывался язык его создателем.
Причем была попытка убедить тамошних гуру о переходе на С++ (в некоторых кусках проекта), ничего не вышло. Ответ как всегда прост, зачем что-то менять, если и так мы двигаемся вперед, используя С? К сожалению есть и объективные причины, по которым переход на новый язык/библиотеку в крупноп проекте довольно сложен, ведь преимущества от перехода на что-то новое, пусть и лучшее требует время, и первый блин будет комом. Т.е. выгода будет, но не завтра, а, скорее, после завтра. А этого, как раз никому и не нужно...
Причем сами же плюются на сложность сопровождения и эволюции. Там куча goto (даже в макросах есть goto "моя метка"), и функции на несколько ТЫСЯЧ строк!!! Модель освобождения ресурсов типа кто-нить должен освободить (память выделена в одной функции освобождается в ПЯТИ различных местах, в зависимости от успешности выполнения последующих функций) и т.д.
Складывается впечатление, что одни зарубежные авторы пишут книги для постсоветского пространства, т.к. тамошние "спецы" эти книги просто не читают.
Вот и получается, что во второй половине первого десятилетия 21-го века начинается проект на С.
А вы буст, буст

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

RO>Библиотеки Boost хорошо документированы, хорошо поддерживаются, единообразны, с простой лицензией. Если в Boost есть что-нибудь, что подходит по всем параметрам, зачем искать дальше?

Скорость? Ресурсоемкость? Распространенность? Возраст? Количество пользователей/успешных внедрений?

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

vsb>Почему бы просто не держать актуальный HOWTO Prepare Build Environment в проекте или в вики?

Почему бы просто не давать программистам возможноть получить готовый build environment одной командной?

vsb>Вроде ничего сложного нет, скачайте буст с 192.168.1.1/files/boost-1.34.tar.bz2, распакуйте, добавьте в environment variable INCLUDE (или что то подобное) и всё. У тех, кто с проектом работает, всё давно настроено, те, кто пришёл недавно, потратят некоторое время, но это ведь происходит достаточно редко. Если надо пропатчить — держать .patch-файлы где-нибудь, патч это одна команда. Можно даже скрипты написать, если сильно хочется автоматизировать.

В идеальном мире идеальные программисты пишут идеальные программы и идеальную документацию к ним.

vsb>Как ни крути, я считаю, что система контроля версий нужна только для контроля версий.

Вам этого никто не запрещает.

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

А я не понимаю смысла выкачивания 25Mb tar.bz2 для возможности использования boost::shared_ptr и boost::bind.

vsb>Кстати я не знаю, для С++ нет аналога maven?

Нет.

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

ST>Вот и получается, что во второй половине первого десятилетия 21-го века начинается проект на С.
ST>А вы буст, буст

а у нас разрешенно писать на C и только на vs6 + sp5 (пять а не последний шестой, попытки перейти на vs2005 были, закончились неудачно)
компания не самая последняя в своей области

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

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

vsb>>>Как ни крути, я считаю, что система контроля версий нужна только для контроля версий.

BZ>ты не сталкивался с тем, что прикладнина неправильно работает с более свежей версией той же библиотеки?

Про свежие версии я не говорил. Несложно зафиксировать версии библиотек, и хранить их на интранетовском сервере (можно даже зафиксировать версии компиляторов, хотя это уже перебор, имхо).

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

ST>Недавно столкнулся с забугорной конторой, которая начала около года назад новый проект, так вот, вся бизнес-логика там на С, и никто не собирается на С++ переходить, не говоря уже за boost. Причем, самое интересное, что контора занимается коммуникациями, именно тем, чем занимается AT&T, т.е. той категорией проектов, ради которых разрабатывался язык его создателем.

Самое важное тут, как всегда одно — как этот софт работает, и насколько он успешно продается. если не глючит больше среднего, и продается, то хоть на zx спектрумовском бейсике пущай будет написано — не дай бог чтото внутри менять.

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

E>А это ты расскажи тому орлу, кто советует при нахождении бага в сторонней библиотеке сразу же править баг в репозитории этой библиотеки.

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

Я считаю, что нормальный ход в этом случае — сообщить разработчикам, а пока хранить патч к бусту в репозитории. Патч, а не целиком буст, поскольку при новой версии библиотеки будет очень сложно понять, где именно жучок засел.
Поэтому компиляция с бустом сводится к:
1. Скачать оригинальный буст из инета или файлового сервера.
2. Применить патч
3. Откомпилировать либ файлы (На крайняк можно сделать так, что бы их брать с файлового сервера, но разработчики при этом будут ограничены в исправлении и отладке буста).

Это можно сделать в скрипте вида make_boost.bat, который разработчик запускает и через пару минут имеет рабочий буст.
Впрочем, это применимо к любой другой библиотеки.

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

С другой стороны я раньше думал, что boost::mpl — для извращенцев, пока не понадобилось подменить тип в зависимости от другого типа. В итоге масштабное изменение в иерархии классов заменилось написанием трех строчек крайне понятного кода.

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

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

vsb>Кстати я не знаю, для С++ нет аналога maven? Там эти проблемы как раз неплохо решены.
Не знаю, какие возможности тебе нужны, но Boost.Build неплох. Основан на Perforce Jam.

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

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

vsb>>Почему бы просто не держать актуальный HOWTO Prepare Build Environment в проекте или в вики?

E>Почему бы просто не давать программистам возможноть получить готовый build environment одной командной?

vsb>>Вроде ничего сложного нет, скачайте буст с 192.168.1.1/files/boost-1.34.tar.bz2, распакуйте, добавьте в environment variable INCLUDE (или что то подобное) и всё. У тех, кто с проектом работает, всё давно настроено, те, кто пришёл недавно, потратят некоторое время, но это ведь происходит достаточно редко. Если надо пропатчить — держать .patch-файлы где-нибудь, патч это одна команда. Можно даже скрипты написать, если сильно хочется автоматизировать.

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

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

RO>>Библиотеки Boost хорошо документированы, хорошо поддерживаются, единообразны, с простой лицензией. Если в Boost есть что-нибудь, что подходит по всем параметрам, зачем искать дальше?

E>Скорость? Ресурсоемкость? Распространенность? Возраст? Количество пользователей/успешных внедрений?

В Boost библиотеки принимаются после peer review. Ты же согласишься, что это подразумевает хоть какой-то минимальный уровень качества? По крайней мере, там не найдешь недоразумений вроде «Reason».

Например, я хочу какую-нибудь маленькую функцию, которая будет возвращать итератор, следующий за данным. У меня есть три варианта:

1. #include <boost/next_prior.hpp>
2. template <class FI> FI next(FI fi) { return ++fi; }
3. Найти и подключить стороннюю библиотеку.

Какой вариант предпочел бы ты?

Или я хочу что-нибудь покрупнее. Например, хочу библиотеку для работы с непересекающимися множествами (это которые disjoint-set). В Boost она есть (а еще где-нибудь?). Чем плохо, если я посмотрю на нее в первую очередь? Т. е., я пойду на www.boost.org/doc/libs, если я найду там то, что нужно, если найденное удовлетворит меня по скорости, ресурсоемкости и прочим параметрам, то возьму и поставлю. Что здесь не так?

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

E>>А это ты расскажи тому орлу, кто советует при нахождении бага в сторонней библиотеке сразу же править баг в репозитории этой библиотеки.

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

Я здесь с нормальными людьми разговариваю или где? Во-первых, какой буст? Я говорил про сторонние библиотеки вообще. Во-вторых, у любого программного проекта есть установленная процедура информирования и исправления багов: как правило -- это баг-репорт, после которого проходит некоторое время (зависит от вменяемости разработчика и живости проекта) и исправления выкладываются либо в публичном репозитории в стабильной ветке, либо в виде патчей, либо в виде свежих дистрибутивов/архивов. В любом случае -- это время. А что в это время делать мне? Я могу либо исправить в своем репозитории, а затем перейти на новую версию библиотеки, либо использовать патчи, а потом перейти на новую версию. Исправление в репозитории проще и надежнее, т.к. не нужно возюкаться со скриптами наката патчей после checkout-ов и update-ов.

_>Я не являюсь фанатиком буста, я — прагматик.

Ахринеть просто: "Использование boost — это отличие новичка от профессионала." Прагматичный подход до мозга костей.

_>Буст действительно не применим во всех ситуациях, но и говорить бусту — никогда в жизни, думаю, тоже не стоит.

Найдите здест того, что сказал бусту "никогда в жизни".

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

RO>>>Библиотеки Boost хорошо документированы, хорошо поддерживаются, единообразны, с простой лицензией. Если в Boost есть что-нибудь, что подходит по всем параметрам, зачем искать дальше?

E>>Скорость? Ресурсоемкость? Распространенность? Возраст? Количество пользователей/успешных внедрений?

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

Не соглашусь. Последние несколько результатов peer review, которые я читал, говорили о том, что даже для принятых в Boost-библиотек было получено не более 10-20 откликов пользователей. И было еще несколько библиотек, которые не прошли peer review, потому что откликов было еще меньше.

Тем не менее, хотелось бы услышать ответ по поводу таких качеств, как скорость и ресурсоемкость.

RO>Например, я хочу какую-нибудь маленькую функцию, которая будет возвращать итератор, следующий за данным. У меня есть три варианта:

RO>1. #include <boost/next_prior.hpp>
RO>2. template <class FI> FI next(FI fi) { return ++fi; }
RO>3. Найти и подключить стороннюю библиотеку.

RO>Какой вариант предпочел бы ты?

std::advance?

Аналогично, мне нужны средства для работы с сокетами и разделяемой паматью. Первый вариант на рассмотрении -- Boost?
Если нужна криптография -- Boost?
Если нужна работа с XML -- Boost?
Если нужна работа с HTTP -- Boost?
Если нужна работа с матрицами -- Boost?
Если нужен GUI -- Boost?
Если нужна работа с БД -- Boost?
Если нужна сериализация -- опять Boost?

RO>Или я хочу что-нибудь покрупнее. Например, хочу библиотеку для работы с непересекающимися множествами (это которые disjoint-set). В Boost она есть (а еще где-нибудь?). Чем плохо, если я посмотрю на нее в первую очередь? Т. е., я пойду на www.boost.org/doc/libs, если я найду там то, что нужно, если найденное удовлетворит меня по скорости, ресурсоемкости и прочим параметрам, то возьму и поставлю. Что здесь не так?

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

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

Сложно что ли посмотреть, что там есть?

E>Аналогично, мне нужны средства для работы с сокетами и разделяемой паматью. Первый вариант на рассмотрении -- Boost?
Да.

E>Если нужна криптография -- Boost?
Нет.

E>Если нужна работа с XML -- Boost?
Нет.

E>Если нужна работа с HTTP -- Boost?
Пока нет.

E>Если нужна работа с матрицами -- Boost?
Да.

E>Если нужен GUI -- Boost?
Пока нет.

E>Если нужна работа с БД -- Boost?
Нет.

E>Если нужна сериализация -- опять Boost?
Да.

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

O>>По поводу нас: думаю многие не используют Буст просто потому, что он им кажется тяжелым (слабенькие спецы).
S>Я слышал что в Японии не рекомендуют использовать классы, т.к. они усложняют код.

Правильно делают. 90% не умеют пользоваться этим инструментом внятно. А 95% — шаблонами. Так что на промышленном уровне вполне внятное ограничение. Результаты налицо.

еще:
1) когда я первый раз заюзал буст — был приятненько удивлен. В каждом проекте нужно писать веловипеды. Удивлен был тем насколько много велосипедов уже реализовано в Библиотеке. Свои Надстройки над Бустом делать легко.

2) Код написанный с использованием буста очень читабелен и компактен. Иногда даже в "священных" спорах C++ vs C# по поводу скорости разработки я утверждаю что если использовать Буст — скорость разработки и отладки на С++ резко возрастает. Думаю это тоже веский аргумент в пользу использования Буста.

прочитав Александреску , решил что неплохо бы еще и ее поюзать. как по мне — весчььь!!!

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

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

N>>Тут вот ради забавы, спросил некоторых товарищей по разным конторам, boost используете?

M>Используем. Легкие вещи (только шаблоны в хидерах) везде, тяжелые (требующие отдельной компиляции бустовских либ) в своих внутренних тулзах.

Аналогично: shared_ptr/array, lexical_cast, tokenizer, string algo, spirit, uBLAS, tuple и т.п.
Требующие компиляции типа filesystem не используем, как правило.

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

E>Тем не менее, хотелось бы услышать ответ по поводу таких качеств, как скорость и ресурсоемкость.

По-разному, как и везде. boost::implicit_cast работает быстро и ресурсов требует мало :-)

RO>>Например, я хочу какую-нибудь маленькую функцию, которая будет возвращать итератор, следующий за данным. У меня есть три варианта:
RO>>1. #include <boost/next_prior.hpp>
RO>>2. template <class FI> FI next(FI fi) { return ++fi; }
RO>>3. Найти и подключить стороннюю библиотеку.
RO>>Какой вариант предпочел бы ты?
E>std::advance?
Он ссылку принимает.

E>Аналогично, мне нужны средства для работы с сокетами и разделяемой паматью. Первый вариант на рассмотрении -- Boost?
E>Если нужна {криптография,сериализация,работа с {XML,HTTP,матрицами,БД}} -- Boost?

Ну да. Увидев, что части требуемого там нет, я пойду за нею в гугл.

RO>>Или я хочу что-нибудь покрупнее. Например, хочу библиотеку для работы с непересекающимися множествами (это которые disjoint-set). В Boost она есть (а еще где-нибудь?). Чем плохо, если я посмотрю на нее в первую очередь? Т. е., я пойду на www.boost.org/doc/libs, если я найду там то, что нужно, если найденное удовлетворит меня по скорости, ресурсоемкости и прочим параметрам, то возьму и поставлю. Что здесь не так?

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

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

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

RO>>>Например, я хочу какую-нибудь маленькую функцию, которая будет возвращать итератор, следующий за данным. У меня есть три варианта:
RO>>>1. #include <boost/next_prior.hpp>
RO>>>2. template <class FI> FI next(FI fi) { return ++fi; }
RO>>>3. Найти и подключить стороннюю библиотеку.
RO>>>Какой вариант предпочел бы ты?
E>>std::advance?
RO>Он ссылку принимает.

Ох ё! Теперь сразу становится понятно, для чего мне нужно добавлять в свой проект зависимость на 25Mb. Только для того, чтобы не писать самому функцию next() или (что, вероятно, совсем плохо) n = c; ++n;

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

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

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

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

RO>Я только и предлагаю начать с Boost, если он там представлен.

Похоже, что мне нужно надеятся, чтобы и ты, и skeptik_, и другие любители Boost-а поступали так и дальше.

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

S>а у нас разрешенно писать на C и только на vs6 + sp5 (пять а не последний шестой, попытки перейти на vs2005 были, закончились неудачно)
S>компания не самая последняя в своей области

По твоим словам склаывается впечатление всего ваш код уже живёт своей жизнью, вы не контролируете его и потому боитесь вносить в него изменения. Давно последний раз рефакторили? Может это и есть причина, по которой не применяют буст в существующих проектах — страх что всё сломается.

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

_>И это будет работать на десятке компиляторов?
Для большого числа применений надо обычно 1-2 компилятора

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

M>По твоим словам склаывается впечатление всего ваш код уже живёт своей жизнью, вы не контролируете его и потому боитесь вносить в него изменения. Давно последний раз рефакторили? Может это и есть причина, по которой не применяют буст в существующих проектах — страх что всё сломается.

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

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

aik>Результаты налицо.

О каком результате речь? Разве японцы хоть сколь-нибуть заметны в IT?

... << RSDN@Home 1.2.0 alpha rev. 786>>

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

O>прочитав Александреску , решил что неплохо бы еще и ее поюзать. как по мне — весчььь!!!

Согласна!

Попробовал новую шоколадку Нестле с лестными орешками и изюмом. Супееер веееесссчччччььь!

O>1) когда я первый раз заюзал буст — был приятненько удивлен. В каждом проекте нужно писать веловипеды. Удивлен был тем насколько много велосипедов уже реализовано в Библиотеке. Свои Надстройки над Бустом делать легко.

+1

O>2) Код написанный с использованием буста очень читабелен и компактен. Иногда даже в "священных" спорах C++ vs C# по поводу скорости разработки я утверждаю что если использовать Буст — скорость разработки и отладки на С++ резко возрастает. Думаю это тоже веский аргумент в пользу использования Буста.

А вот тут немного не согласен. Всетаки отладка с boost немного тяжелее, по той причине что структура хранения данных хотя бы в том multi_index довольно не простая. Хотя вот существует визуализатор к студии, но мне почему то прикрутить его не удалось. Может добрые люди подскажут как это сделать?

DmitryKarpov пишет:
>
> являются или фанатичными или следующими моде или просто глупыми.
Так я яйца с какого конца бить надо?

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

Posted via RSDN NNTP Server 2.1 beta

Sni4ok пишет:
>
> часть самого stl'я также юзать запрещается, а вместо
> этого предложено пользоваться замечательными велосипедами — аля умными
> указателями, строками, векторами и прочими матыгами.
Ну например они пишут под однокристалки, DSP процы.

))

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

Posted via RSDN NNTP Server 2.1 beta

eao197 пишет:
>
>
> У меня спокойное отношение к бусту -- на данный момент мне из него
> ничего не нужно. А вот отношение к оголтелым бустоманам такое же, как у
> атеиста к религиозным фанатиками.
Это похоже ("колокола с церквей сшибать") — только оно неспокойное.
Лично мне буст нравиться, что там есть куча велосипедов в той или иной
степени отлаженных, причем работающих, в отличие от мелких различных
поделок с квадратными колесами. Но всему свое место, в зависимости от
задачи.

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

Posted via RSDN NNTP Server 2.1 beta

minorlogic пишет:
>
>
> Тут на форуме длинные ветки по поводу STL есть , а вы буст буст ...
Пора их в священные войны перегонять.

Posted via RSDN NNTP Server 2.1 beta

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

SD>Это не только буста касается. Любой давно живущий проект, ведомый плохим менеджментом, всегда скатывается в такое болото, когда начинается страх "как бы чего не сломалось".

софтина работает на двух типах серверов. В коде приходиться учитывать различия в версиях серверов и изменения внесенные отдельными апдейтами. Клиенты крупные и если сервер повиснит по наше вине будет плохо.

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

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

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

aik>>Результаты налицо.

L>О каком результате речь? Разве японцы хоть сколь-нибуть заметны в IT?

Вот вам и результат.

... << RSDN@Home 1.2.0 alpha 4 rev. 1091>>

Что именновы хотите из нее поюзать ?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

sergey2b wrote:
> Здравствуйте, SkyDance, Вы писали:
>
> SD>Это не только буста касается. Любой давно живущий проект, ведомый плохим менеджментом,
> всегда скатывается в такое болото, когда начинается страх "как бы
чего не сломалось".
>
> софтина работает на двух типах серверов. В коде приходиться учитывать различия в версиях серверов
> и изменения внесенные отдельными апдейтами. Клиенты крупные и если сервер повиснит по наше вине будет плохо.
>
> Я понимаю что вы правы но когда в случаи бага могут поднять в любое время суток, прежде чем что то менять подумаешь 10 раз.

А тестировани есть? Не в виде 'запустил, нажал, вроде работает', а с
воспроизведением разных ситуаций, стресс тестирование и т.п.?

Posted via RSDN NNTP Server 2.1 beta

M>Что именновы хотите из нее поюзать ?

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

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

O> Меня впечатлили паттерны которые там реализованы ....
Какие именно патерны? можно конкретнее

O>а еще я думаю что Списки типов коорые там тоже реализованы позволяют наращивать функциональность и , как бы это сказать , расширяют поле деятельности для созданя полезного повторно используемого кода

Списки типов смотрели в бусте ? Например в boost::fusion::vector ?

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

E>>>2. Движение C++ников по созданию новой стандартной библиотеки для C++ (типа нашего ответа Чемберленам JDK и .NET Framework).

E>>>Имхо, вторая составляющая в спорах вокруг Boost-а является доминирующей.

KV>>Кстааати, (раз уж выделенное тут прозвучало), в чем преимущества буста перед дотнетом?

E>Боюсь, этот вопрос сродни вопросу о преимуществе бананов перед помидорами.

Тогда как оно может являться ответом управляемому Чемберлену?

H>>Некоторые библиотеки буст — редкостное дерьмо.
_>Пример можно? Насколько я понимаю, Вы настолько круты, что одной левой напишете лучше? И это будет работать на десятке компиляторов? Вас как зовут? Саттер или Мейерс?

В этой ветке уже четыре раза прозвучало TRE vs. Boost::Regex
Тут уже говорилось про XML

_>Сложно что ли посмотреть, что там есть?

E>>Аналогично, мне нужны средства для работы с сокетами и разделяемой паматью. Первый вариант на рассмотрении -- Boost?
_>Да.

E>>Если нужна криптография -- Boost?
_>Нет.

E>>Если нужна работа с XML -- Boost?
_>Нет.

E>>Если нужна работа с HTTP -- Boost?
_>Пока нет.

E>>Если нужна работа с матрицами -- Boost?
_>Да.

E>>Если нужен GUI -- Boost?
_>Пока нет.

E>>Если нужна работа с БД -- Boost?
_>Нет.

E>>Если нужна сериализация -- опять Boost?
_>Да.

Это и есть ответ на http://rsdn.ru/forum/message/3045475.1.aspx

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

H>>>Некоторые библиотеки буст — редкостное дерьмо.
_>>Пример можно? Насколько я понимаю, Вы настолько круты, что одной левой напишете лучше? И это будет работать на десятке компиляторов? Вас как зовут? Саттер или Мейерс?

M>В этой ветке уже четыре раза прозвучало еvs. Boost::Regex
M>Тут уже говорилось про XML
И при чём здесь XML? Товарищ выдвинул утверждение -- "Некоторые библиотеки буст — редкостное дерьмо.". XML в бусте нет. Как несуществующая библиотека может быть дерьмом?
А TRE рядом с творением Мэддока даже рядом не стояло.

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

M>ЗЫ. Если XML'я в бусте нет, и я уже использую библиотеку, в которой он есть, и которая предоставляет аналоги из буста, зачем мне буст?

Вам -- незачем. Можете даже писать на голом компиляторе, используя исключительно функции операционки. Всё остальное -- от лукавого.

M>>ЗЫ. Если XML'я в бусте нет, и я уже использую библиотеку, в которой он есть, и которая предоставляет аналоги из буста, зачем мне буст?

_>Вам -- незачем. Можете даже писать на голом компиляторе, используя исключительно функции операционки. Всё остальное -- от лукавого.

Блин. Почему такие крайности? Почему или обязательно буст или голый компилятор или кривые велосипеды? Почему не тот же loki?

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

E>Дима, ну ты прям как маленький! Другие библиотеки ведь искать нужно, сравнивать, выбирать. А Boost -- вот он, готовенький, все про него знают. В нем все есть, а чего сейчас нет, то когда-нибудь будет, а сейчас оно и не надо. Берешь и пользуешься, короче говоря. Да и еще и осознаешь себя продвинутым C++ником: как же, я же Boost знаю, использую его, помогаю делать новую стандартную библиотеку для C++.

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

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

E>Отличие Boost-а от таких библиотек, как ACE, Poco, Qt или wxWidgets состоит в том, что прием новых библиотек в Boost осуществляется на основании откликов пользователей на новые библиотеки. Т.е. некий Вася Пупкин решил, что его библиотека достойна принятия в Boost, оформил ее в соответствии с требованиями Boost-а, сообщил о ней Boost-оводам, те сделали предварительную оценку, потом вывели на публичное обсуждение. Набрала библиотека достаточное количество голосов -- попала в Boost. Насколько она будет нужна конечным пользователям -- это отдельный вопрос и я не знаю, как он учитывается при приеме новых библиотек в Boost.

Насчёт нужности -- последний ревью это как раз демонстрирует. Библиотека Egg -- вроде неплохо сделано, но! народ как-то не заинтересовался, и несмотря на обсуждение, был получен только один отзыв. Этого недостаточно, всё -- библиотека в пролёте. Я вот скажем не вникал, но мимолётным взгядом тоже не понял, зачем она нужна. Вот со следующим ревью такого я думаю не произойдёт -- FSM, вещь в хозяйстве незаменимая, и сделано гораздо эффективней, чем старый вариант. Если народ явных изъянов не найдёт, то она, я думаю, войдёт в буст. Автор кстати русский.

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

_>Насчёт нужности -- последний ревью это как раз демонстрирует. Библиотека Egg -- вроде неплохо сделано, но! народ как-то не заинтересовался, и несмотря на обсуждение, был получен только один отзыв. Этого недостаточно, всё -- библиотека в пролёте. Я вот скажем не вникал, но мимолётным взгядом тоже не понял, зачем она нужна. Вот со следующим ревью такого я думаю не произойдёт -- FSM, вещь в хозяйстве незаменимая, и сделано гораздо эффективней, чем старый вариант. Если народ явных изъянов не найдёт, то она, я думаю, войдёт в буст. Автор кстати русский.

Я знаю еще несколько примеров таких же незаменимых вещей, как FSM -- spirit, expressive, wave, foreach, gil, graph, lambda, mpi, mpl, preprocessor, python, serialization, ublas. Т.е. кому-то они явно нужны и кто-то жить без них не может. Но вот мне -- ну ни в Красную Армию. Тем не менее, если мне потребуется boost::multi_index, то придется тянуть к себе весь boost со всей этой байдой.

M>>Блин. Почему такие крайности? Почему или обязательно буст или голый компилятор или кривые велосипеды? Почему не тот же loki?

E>Дима, ну ты прям как маленький! Другие библиотеки ведь искать нужно, сравнивать, выбирать. А Boost -- вот он, готовенький, все про него знают. В нем все есть, а чего сейчас нет, то когда-нибудь будет, а сейчас оно и не надо. Берешь и пользуешься, короче говоря. Да и еще и осознаешь себя продвинутым C++ником: как же, я же Boost знаю, использую его, помогаю делать новую стандартную библиотеку для C++.

Не, ну так нечестно. пришли и все разжевали

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

E>Ну да. Только тут сочетается два принципа, которые приводят меня в бешенство: "Есть только один правильный способ делать вещи" и "Кто не с нами, тот против нас".

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

E>Вот например. Boost.Serialization или Boost.Regex не единственные библиотеки подобного рода для C++. Наверняка в какой-то области они для кого-то лучше других, а в какой-то хуже. Тем не менее, они обе находятся в более выигрышном положении по отношении к другим подобным библиотекам. Если пользователи выбирают их только потому, что они есть в Boost-е, а пользователь уже знаком с Boost-ом, то, в конечном счете, пользователи обкрадывают самих себя, лишая себя возможности использования более достойной альтернативы (в каких-то условиях).

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

E>В конце-концов, это обычное дело в области продуктов массового потребления (95% потребителей, по заверениям Генри Форда, готовы брать то, что им предлагают, если это достаточного хорошего качества и по приемлимой цене). Но, когда речь идет о инструментарии для разработки ПО нужно понимать, что любая библиотека имеет недостатки. Будь то Boost или STL. И могут быть условия, при которых лучше отказаться от мейнстримовых инструментов в пользу чего-то экзотического. Однако, когда я вижу фанатичное доказывание, что Boost -- наше все, мне кажется, что такого понимания возникнуть не может.

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

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

E>>Ну да. Только тут сочетается два принципа, которые приводят меня в бешенство: "Есть только один правильный способ делать вещи" и "Кто не с нами, тот против нас".

M>Я понимаю про какие ты принцыпы пишешь и откуда ты их взял.

"Есть только один правильный способ делать вещи" появился из:
— фактов того, что в Boost-е реализуют по своему функциональность, уже существующую в других библиотеках. Например, asio и interprocess;
— утверждений пользователей Boost-а о том, что Boost-овские библиотеки круче других (см. здесь: "А TRE рядом с творением Мэддока даже рядом не стояло.").

А "кто не с нами, тот против нас" -- так это здесь чувствуется чуть ли не с начала темы:
здесь:

Ничего удивительно. Уровень программистов такой. Во многих конторах и к
STL до сих пор предубеждение. Зато очень любят голые указатели.

здесь:

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

здесь:

А не используют по контором мне кажется вот по какой причине.
В каждой конторе есть гуру, которому все верят и вот приходит человек горит, эй! давайте boost использовать будем, это ведь так и так и сяк, нам поможет, гуру косо посмотрит, потом одним глазом доку по бусту на искосок просмотрит и скажет... не фигня... тут можно обойтись этим и этим.

Все это наводит на мысль, что у некоторого количества людей складывается стереотип "Boost -- это хорошо и правильно. А вот не Boost -- это слабенькие спецы/старые пердуны и пр."

M>Если ты думаешь что используя буст не можешь больше использовать ACE например, это не так.

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

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

Ну кому-то же нужно повторять "Карфаген должен быть разрушен!". А то очень удобно считать, что Boost это классная и полезная штука. Не обращая внимания на то, что определенное количество разработчиков видят в Boost-е недостатки. И на то, что могут быть другие пути развития C++ных библиотек и систем их распространения.

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

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

E>>>Ну да. Только тут сочетается два принципа, которые приводят меня в бешенство: "Есть только один правильный способ делать вещи" и "Кто не с нами, тот против нас".

M>>Я понимаю про какие ты принцыпы пишешь и откуда ты их взял.

E>"Есть только один правильный способ делать вещи" появился из:
E>- фактов того, что в Boost-е реализуют по своему функциональность, уже существующую в других библиотеках. Например, asio и interprocess;
E>- утверждений пользователей Boost-а о том, что Boost-овские библиотеки круче других (см. здесь: "А TRE рядом с творением Мэддока даже рядом не стояло.").
Я юзал Boost.Regex. Это в большинстве случаев 1-2 строчки. Смотришь примеры, и сразу всё ясно. И почему собственно пишут заново? Потому что многие старые либы с современным С++ несовместимы. Попробуй заюзать например шаблоны в Qt...

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

E>Все это наводит на мысль, что у некоторого количества людей складывается стереотип "Boost -- это хорошо и правильно. А вот не Boost -- это слабенькие спецы/старые пердуны и пр."

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

E>Я думаю, что если кто-то взялся за Boost, то ему уже не объяснить, зачем может потребоваться ACE.

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

E>Ну кому-то же нужно повторять "Карфаген должен быть разрушен!". А то очень удобно считать, что Boost это классная и полезная штука.

А я именно так и считаю, что "Boost это классная и полезная штука." и мне это очень удобно.

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

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

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

E>Вот, например, если кто-то предпочитает использовать функции open/read/write/lseek вместо std::fstream -- это показатель непрофессионализма? А если кто-то не использует std::map из-за высоких накладных расходов последнего -- это что?
Ага. А взамен такой товарищ будет юзать самописный список с линейным поиском. Плавали, знаем.

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

M>>А я именно так и считаю, что "Boost это классная и полезная штука." и мне это очень удобно.

E>Ну и хорошо. Но это не объясняет, почему пользователи Boost-а с таким апломбом зявляют "Я использую Boost". Вот ты можешь объяснить?

Объясняли вообще-то уже. А вот один противник тут крикнул -- "Некоторые либы в бусте — дерьмо!", но на конкретную просьбу назвать оные скромно удалился.

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

M>>>А я именно так и считаю, что "Boost это классная и полезная штука." и мне это очень удобно.

E>>Ну и хорошо. Но это не объясняет, почему пользователи Boost-а с таким апломбом зявляют "Я использую Boost". Вот ты можешь объяснить?

_>Объясняли вообще-то уже.

Где?

_>А вот один противник тут крикнул -- "Некоторые либы в бусте — дерьмо!", но на конкретную просьбу назвать оные скромно удалился.

Ну я одну такую могу назвать: lexical_cast. Тормозная и ресурсоемкая штука. К тому же негибкая.

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

E>Понятно. Попробуй устроится в контору с нормальным уровнем разработки на C++.

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

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

_>>>А вот один противник тут крикнул -- "Некоторые либы в бусте — дерьмо!", но на конкретную просьбу назвать оные скромно удалился.

E>>Ну я одну такую могу назвать: lexical_cast. Тормозная и ресурсоемкая штука. К тому же негибкая.

_>

Её тормознутость как раз от гибкости-то и происходит! Ибо она учтёт при конвертировании все пожелания твоей локали.

Если она такая гибкая, то как в вызове:

lexical_cast<std::string>(2048u)

получить шестнадцатиричное число с префиксом 0x?

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

E>А вот пусть не наводит. Почему предположить, что программист не использует стандартную библиотеку C++ по объективным причинам сложнее, чем предположить, что это недоучка или старый пердун?

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

E>Вот, например, если кто-то предпочитает использовать функции open/read/write/lseek вместо std::fstream -- это показатель непрофессионализма?

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

E>А если кто-то не использует std::map из-за высоких накладных расходов последнего -- это что?

Это голословное утверждение. Накладные расходы можно обсуждать только в приложении к решаемой задаче и альтернативными решениями. А вот использование std::map для ассоциативной связи по ключу это прямое и просто решение.

E>А теперь давай вспомним, кто здесь кричал, что boost отстой? И ты уверен, что критики boost в данной ветке не способны понять, как им пользоваться и как он устроен? Мне кажется, ты здесь говоришь о каком-то гипотетическом разработчике.
Хорошо , не будем рассматривать этого гип. разраба.

M>>А я именно так и считаю, что "Boost это классная и полезная штука." и мне это очень удобно.

E>Ну и хорошо. Но это не объясняет, почему пользователи Boost-а с таким апломбом зявляют "Я использую Boost". Вот ты можешь объяснить?

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

E>Ты сейчас говоришь о недостатках в реализации каких-то библиотек. Я же говорю о недостатках Boost как некоего движения разработчиков. Одна большая "правильная" библиотека -- это то, что я не хочу видеть как будущее для C++.

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

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

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

_>>>>А вот один противник тут крикнул -- "Некоторые либы в бусте — дерьмо!", но на конкретную просьбу назвать оные скромно удалился.

E>>>Ну я одну такую могу назвать: lexical_cast. Тормозная и ресурсоемкая штука. К тому же негибкая.

_>>

Её тормознутость как раз от гибкости-то и происходит! Ибо она учтёт при конвертировании все пожелания твоей локали.

E>Если она такая гибкая, то как в вызове:
E>

E>lexical_cast<std::string>(2048u)
E>

E>получить шестнадцатиричное число с префиксом 0x?

Тебе не кажется, что ты путаешь божий дар с яичницей? lexical_cast предназначен для простого преобразования из одного типа в другой. То, что ты хочешь, это — форматирование. Смотри boost::format например.

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

E>Понятно, т.е. вместо кода:
E>

E>int result = do_something();
E>if( result )
E>  throw some_exception( "do_something failed with result: " + slexcast( result, hex_0x ) );
E>

E>мне нужно будет делать что-то вроде:
E>

E>int result = do_something();
E>if( result )
E>  throw some_exception( "do_something failed with result: " +
E>    (format( "0x%x" ) % result).str() );
E>

Формировать строку сообщения об ошибке в throw — не лучший способ. Во-первых, там лучше особо сложных вещей не делать, дабы не кинуть новое исключение; во-вторых: желаю массу удовольствий при интернационализации программы. В-третьих, если slexcast столь хороша -- предложи её в буст. В-четвертых, я особой разницы между этими двумя вариантами не вижу.

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

E>>А вот пусть не наводит. Почему предположить, что программист не использует стандартную библиотеку C++ по объективным причинам сложнее, чем предположить, что это недоучка или старый пердун?

M>Я полагаю что таких причин нет.

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

E>>А если кто-то не использует std::map из-за высоких накладных расходов последнего -- это что?

M>Это голословное утверждение. Накладные расходы можно обсуждать только в приложении к решаемой задаче и альтернативными решениями. А вот использование std::map для ассоциативной связи по ключу это прямое и просто решение.

Не голословное. В STL-ях, насколько мне известно, std::map реализуется через деревья (вроде как самая распространенная реализация -- это красно-черные деревья). Новые элементы дерева выделяются через new. Это может оказывать следующие негативные эфекты:
1. При небольшом размере контейнера (скажем 20-100 элементов) и небольших размерах элементов (вроде нескольких int-ов) обычный вектор с тупым линейным поиком и перемещением элементов при вставке/удалении будет эффективнее, т.к. эти операции все равно будут дешевле, чем new/delete (особенно в многопоточной программе с очень дорогими new/delete). А если добавить еще и двоичный поиск...
2. В долгоживущем map-е узлы дерева запросто могут оказаться на разных страницах памяти. И при поиске элемента возможны промахи мимо кэша, когда очередной страницы с единственным элементом дерева нет в кэше. А на современных процесорах промах мимо кэша обходится очень дорого.

Так что в ряде случаев более эффективными, чем std::map будут простые вектора, хэш-таблицы или деревья на основе B+ деревьев.

M>Ну извини , если тебе слышится апломб , тогда это не ко мне . скорее к психологу.

Ну извини, если тебе слышится в моих словах фанатичное неприятие boost-а. Тогда это не ко мне...

M>Я не пониамаю тебя. Буст стремится объеденить лучшее что есть в индустрии с оглядкой на принцыпы залорженные в C++ и его библиотеках. Если есть билиотека решающая поставленные задачи лучеш чем решение в бусте , я не вижу причин по которым бы эта библиотека не вытеснила бустовскую и не заняла ее место.

Поскольку в параллельных мирах эти же вопросы решают совсем по другому. В Ruby есть RubyGems, в Java есть Maven2. Селекция библиотек производится путем естественного отбора. Пользователи сами делают что-то де-факто стандартом предпочитая один RubyGem другому.

Мне подобная схема более симпатична и близка, чем монолитный Boost с редкими релизами и процедурами review.

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

E>>>>Понятно. Попробуй устроится в контору с нормальным уровнем разработки на C++.

_>>>Спасибо, я уж как-нибудь дальше фрилансером. И денег в три раза больше, и свободы.

E>>Как, тебе хватает $100 в месяц?

_>Мне хватает 70 евро в час.

Где же ты таких лохов находишь?

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

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

E>>>>>Понятно. Попробуй устроится в контору с нормальным уровнем разработки на C++.

_>>>>Спасибо, я уж как-нибудь дальше фрилансером. И денег в три раза больше, и свободы.

E>>>Как, тебе хватает $100 в месяц?

_>>Мне хватает 70 евро в час.

E>Где же ты таких лохов находишь?

Ась? Стандартная ставка для специалиста с уровнем выше среднего вообще-то...

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

E>>>>Как, тебе хватает $100 в месяц?

_>>>Мне хватает 70 евро в час.

E>>Где же ты таких лохов находишь?

_>Ась? Стандартная ставка для специалиста с уровнем выше среднего вообще-то...

Так тож для специалистов. Да еще уровнем выше среднего...

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

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

E>>>>>Как, тебе хватает $100 в месяц?

_>>>>Мне хватает 70 евро в час.

E>>>Где же ты таких лохов находишь?

_>>Ась? Стандартная ставка для специалиста с уровнем выше среднего вообще-то...

E>Так тож для специалистов. Да еще уровнем выше среднего...

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

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

_>Аргументы, как я понимаю, кончились?

А мне надоело в одиночку аргументы приводить.

_>Пошли в ход оскорбления?

Это был откровенный стеб, после понтов о фрилансерстве.

_>Я был о тебе, честно говоря, лучшего мнения.

Всем свойственно ошибаться. В конце-концов, мы же в "Священных воинах" находимся. Здесь исключением является конструктивный разговор.

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

_>>Пошли в ход оскорбления?

E>Это был откровенный стеб, после понтов о фрилансерстве.

Какие понты? Я 15 лет живу в Германии, здесь такие ставки для фрилансеров -- обычное дело, средняя сейчас — 65 евро. SAP'шники так и того больше зарабатывают.

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

M>Я не пониамаю тебя. Буст стремится объеденить лучшее что есть в индустрии с оглядкой на принцыпы залорженные в C++ и его библиотеках. Если есть билиотека решающая поставленные задачи лучеш чем решение в бусте , я не вижу причин по которым бы эта библиотека не вытеснила бустовскую и не заняла ее место.

Мы тут, конечно, все не Грибоедовы, но хотя бы чуть-чуть текст на опечатки можно проверять?
(Фанаты буста проигрывают по русскому языку)

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

_>И за 11-12 лет ты к своим либом даже юнит-тесты не собрался прикрутить?

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

Если не ошибаюсь, 12-ть лет назад unit-тесты широко использовались разве что Кентом Беком.

_>Короче, говорить тут не о чём. Велосипед -- он и есть велосипед.

Да, я люблю строить велосипеды. Временами это получается.

_>А то, что велосипеды используются дальше, когда появились production quality аналоги -- это уже клиника.

В моих условиях проще пользоваться своим маленьким велосипедом, чем production quality паровозом Boost-а.

_>Да, вот ты сказал, что boost::lexical_cast это плохо, ибо тормозит и негибко. И что slexcast это круто. Ну что ж, смотрим в код, и видим:
_>

_>template< class From, class Putter >
_>std::string
_>slexcast(
_>    //! Что преобразуется.
_>    const From & f,
_>    //! Как преобразуется.
_>    const Putter & putter )
_>{
_>    std::stringstream    ss;
_>    putter( ss, f );

_>    return ss.str();
_>}
_>

_>и ты хочешь сказать, что это быстрее чем boost::lexical_cast или гибче чем boost::format?

Я хочу сказать, что это гибче, чем boost::lexical_cast. А на произвольных пользовательских типах не медленнее. И проще в нужных use case-ах, чем boost::format.

_>Комментарии нужны, или и так всем всё ясно?

Я бы послушал

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

E>Понятно, т.е. вместо кода:
E> throw some_exception( "do_something failed with result: " + slexcast( result, hex_0x ) );
E>мне нужно будет делать что-то вроде:
E> throw some_exception( "do_something failed with result: " +
E> (format( "0x%x" ) % result).str() );
E>[/ccode]

На всякий случай, в Boost.Format это выглядит иначе:

throw some_exception(str(boost::format("do_something failed with result: 0x%x") %result));
throw some_exception(str(boost::format("Oops! Result = 0x%1$x (%1%), error = %2%") %errno %strerror(errno)));

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

E>Имхо, Boost.Build может нравится только тем, кто нормальных инструментов не видел, т.к. SCons, qmake, Rake, CMake, MPC, Mxx_ru.

В порядке интереса, а чем же Boost.Build плох?

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

E>>Имхо, Boost.Build может нравится только тем, кто нормальных инструментов не видел, т.к. SCons, qmake, Rake, CMake, MPC, Mxx_ru.

VE>В порядке интереса, а чем же Boost.Build плох?

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

Но сравнению с Boost.Build такие вещи, как SCons и MPC осваиваются гораздо проще. При этом SCons еще и построен на базе нормального языка программирования (как и Rake, Mxx_ru).

Если бы сейчас поиск на RSDN работал, то можно было бы попробовать найти обсуждения Boost.Build-а в форумах по C++.

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

E>Когда я года четыре назад пытался найти замену mxx4 чтобы переползти на одну экзотическую платформу, то смотрел на Boost.Build в попытке добавить туда поддержку нужного мне компилятора. Сейчас уже не помню подробностей, но у меня осталось впечатление, что Boost.Build -- это такая адская смесь недо-make и недо-языка программирования. Из особенно ярких воспоминаний -- необходимость ставить пробелы перед завершающими строку точками с запятой.

Пробел многих раздражает почему-то

E>Но сравнению с Boost.Build такие вещи, как SCons и MPC осваиваются гораздо проще. При этом SCons еще и построен на базе нормального языка программирования (как и Rake, Mxx_ru).

Не знаю, может, изменилось что-то, но, по-моему, буст.билд очень просто осваивается.
Возможно, у меня требования небольшие, но что такого особенного умеет, например SCons?

E>Если бы сейчас поиск на RSDN работал, то можно было бы попробовать найти обсуждения Boost.Build-а в форумах по C++.
Да, с поиском что-то не то

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

_>>cpp_util_2 => Boost.Conversion + noncopyable + Function

E>+ еще адаптация к особенностям разных компиляторов. И все это в нескольких килобайтах архива.
E>Эксперименты с unary_method -- это так, попытка приобщится к modern C++ design. В будущем я его вообще оттуда выкину.
E>Новые версии cpp_util_2 я вообще очень давно на сайт не выкладывал, а там появились новые вещи, например, hex_dump::string_dumper, hex_dump::hex_escaped_string_dumper, string_piece, temporary_object_ref.

Выложил на сайт последнюю версию cpp_util_2. Документации в on-line нет, т.к. она генерируется doxygen-ом в utf-8, а narod.ru этого очень не любит. Зато есть ее архив.

Там в документации есть специальный раздел, посвященный lexcast/slexcast с объяснением того, почему я сделал lexcast вместо использования boost::lexical_cast.

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

E>>Но сравнению с Boost.Build такие вещи, как SCons и MPC осваиваются гораздо проще. При этом SCons еще и построен на базе нормального языка программирования (как и Rake, Mxx_ru).

VE>Не знаю, может, изменилось что-то, но, по-моему, буст.билд очень просто осваивается.
VE>Возможно, у меня требования небольшие, но что такого особенного умеет, например SCons?

К сожалению, у меня нет времени на то, чтобы заново ознакомится с Boost.Build и SCons-ом, чтобы провести такое сравнение. Насколько я помню, самое важное -- это различие в подходах. Boost.Build -- это развитие make, тогда как SCons -- это подход на основе шаблонов. Человек в SCons (MPC, Mxx_ru) просто указывает какую цель ему нужно достичь, а формирование make-правил берет на себя SCons.

Итогом этого является то, что проектный файл в SCons (MPC, Mxx_ru) больше напоминает обычную маленькую простую программу. Тогда как в Boost.Build это make-правила со всякими особенностями, присущими make.

Все субъективно, естественно.

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

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

H>Посмотрел boost regex и в ужасе перешел на TRE.

Ну и что тебя там напугало? Уже пятый пост шарахаешся?
Возьми тогда boost::xpressive или опять душа в пятки?

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

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

M>А если кричит что буст это отстой и при этом не строчки не зная и не понимая как это работает
Аналогично. Если от буста отказались после длительного применения?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

_>Ага. А взамен такой товарищ будет юзать самописный список с линейным поиском.
Неверно.

_>Плавали, знаем.
Ну вот и понятно в какой субстанции плавали и соответственно что об этом знаете.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

_>>Ага. А взамен такой товарищ будет юзать самописный список с линейным поиском.
CC>Неверно.

_>>Плавали, знаем.
CC>Ну вот и понятно в какой субстанции плавали и соответственно что об этом знаете.

Нет, просто доводилось исправлять так написанные продукты.

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

_>Нет, просто доводилось исправлять так написанные продукты.
Дык я про то, что не те вам люди попадались.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

Не забывай что у кода есть очень важный фактор "сопровождаемость". Даже представить себе не могу как некий функциональный аналог STL может дать не худшую сопровождаемость или компенсировать потерю оной какими либо преимуществами. Очень хочу увидеть пример, и надеюсь не очередной велосипед с кривыми колесами и отсутствием покрытия тестами и документации.

M>>А если кричит что буст это отстой и при этом не строчки не зная и не понимая как это работает
CC>Аналогично. Если от буста отказались после длительного применения?

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

M>Не забывай что у кода есть очень важный фактор "сопровождаемость". Даже представить себе не могу как некий функциональный аналог STL может дать не худшую сопровождаемость или компенсировать потерю оной какими либо преимуществами.

Qt, MFC, wxWidgets. Ранее на них можно было программировать вообще без использования STL. На Qt, насколько я понимаю, это можно продолжать делать и сейчас (там собственные строки, контейнеры, файлы и пр.) Причем, если Qt3 еще была исключительно Desktop-ориентированной библиотекой, то Qt4 уже разделена на Core и GUI части, так что на Qt4 уже можно server-side делать.

M> Очень хочу увидеть пример, и надеюсь не очередной велосипед с кривыми колесами и отсутствием покрытия тестами и документации.

Закрадываются у меня смутные сомнения, что это камешек в мой огород.

M>>>А если кричит что буст это отстой и при этом не строчки не зная и не понимая как это работает
CC>>Аналогично. Если от буста отказались после длительного применения?

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

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

Boost.Regex vs PCRE vs Greta vs TRE vs POSIX
Boost.Serialization vs s11n.net
Boost.Random vs Agner Random Library
Boost.SmartPtr vs ACE vs Qt vs Loki vs STLSoft vs Poco vs еще много чего.
Boost.Filesystem vs ACE vs STLSoft vs Qt vs wxWidgets vs Poco vs еще много чего.
Boost.Interprocess vs ACE vs Qt vs Poco
Boost.Asio vs ACE vs Qt vs Poco

(disclaimer: в возможностях каких-то библиотек я могу ошибаться).

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

M>>Не забывай что у кода есть очень важный фактор "сопровождаемость". Даже представить себе не могу как некий функциональный аналог STL может дать не худшую сопровождаемость или компенсировать потерю оной какими либо преимуществами.

E>Qt, MFC, wxWidgets. Ранее на них можно было программировать вообще без использования STL. На Qt, насколько я понимаю, это можно продолжать делать и сейчас (там собственные строки, контейнеры, файлы и пр.) Причем, если Qt3 еще была исключительно Desktop-ориентированной библиотекой, то Qt4 уже разделена на Core и GUI части, так что на Qt4 уже можно server-side делать.

В данном случае я бы дал оценку , что использование сторонней библиотеки "Qt, MFC, wxWidgets" не дает преимуществ которые бы компенсировали падение сопровождаемости. Готов рассмотреть сценарий конда в группе на большинстве проектов используется Qt и всем разработчикам необходимы навыки работы с ней (поэтому порог вхождения есть только у новичков и то полюбому).

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

E>Boost.Regex vs PCRE vs Greta vs TRE vs POSIX
E>Boost.Serialization vs s11n.net
E>Boost.Random vs Agner Random Library
E>Boost.SmartPtr vs ACE vs Qt vs Loki vs STLSoft vs Poco vs еще много чего.
E>Boost.Filesystem vs ACE vs STLSoft vs Qt vs wxWidgets vs Poco vs еще много чего.
E>Boost.Interprocess vs ACE vs Qt vs Poco
E>Boost.Asio vs ACE vs Qt vs Poco

E>(disclaimer: в возможностях каких-то библиотек я могу ошибаться).

Насколько я помню , к примеру , ACE достоаточно серьезно рассматривался как кандидат в буст. Почему его не включили а начали писать Boost.Asio(мегасырой продукт) я не знаю. Уверен что причины были и их можно найти в мейл листе.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

Я высказываю свою оценку а не пытаюсь доказать что либо.

E>Более того, лично на придерживаюсь противоположной точки зрения. Скажем, при разработке GUI приложения использование только Qt-шных средств (включая строки и контейнеры) упростит приложение, т.к. средства Qt изначально увязаны друг с другом, а поддержка STL в Qt является опциональной. Для примера можно взять одновременное использование std::string и QString: необходимость преобразования данных между типами, что выливается в лишний (по сути, мусорный) код и снижение производительности.

Вполне обоснованно. Но в описанном случае есть достаточно серьезные причины использовать QString вместо std::string. Хотя и в этом сценарии модель данных лучше реализовать без участия QString.

E>Да ладно, фиг с ним, с ACE. У многих существуют достаточно обоснованные претензии к качеству реализации ACE. Но вот что по поводу других альтернатив библиотекам Boost-а, которые были упомянуты мной выше?

К сожелению не могу прокоментировать сотояние и сравнительный анализ этих библиотек. Я с ними не работал и не проводил оценку и историю использования. Из библиотек которые я примерно представляю себе плюсы и минусы это GIL.

E>Я, например, знаю одну Boost-овскую библиотеку, аналога которой больше не встречал -- MultiIndex.

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

M>>>А меня вот не наводит. И еще если програмист на С++ не пользуется стандартной билиотекой по умолчанию, это уже наводит меня на определенные мысли.
CC>>Интересно. А что ты скажешь если программист не пользуется стандартной билиотекой по умолчанию, но при этом хорошо ее знает и имеет серьезный опыт ее применения?
_>Unreal.
Отнюдь.

M>>>А если кричит что буст это отстой и при этом не строчки не зная и не понимая как это работает
CC>>Аналогично. Если от буста отказались после длительного применения?
_>Пример можешь привести? Нет?
Приезжай — покажу, тыкая пальцем.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

M>>>А меня вот не наводит. И еще если програмист на С++ не пользуется стандартной билиотекой по умолчанию, это уже наводит меня на определенные мысли.
CC>>Интересно. А что ты скажешь если программист не пользуется стандартной билиотекой по умолчанию, но при этом хорошо ее знает и имеет серьезный опыт ее применения?
M>Не забывай что у кода есть очень важный фактор "сопровождаемость". Даже представить себе не могу как некий функциональный аналог STL может дать не худшую сопровождаемость или компенсировать потерю оной какими либо преимуществами.
Может. С чего ты взял что если аналог то сразу не сопровождаем? Или априори считается что STL и Boost пишутся некими суперпрограммистами из космоса которые больше нигде не водятся?
Чем так сложен тот же STL, чего не может написать команда проф. программистов? Неужели так сложно написать map на B+ tree? Или deque с бОльшим чем в стандартном STL размером блока?

M> Очень хочу увидеть пример
Из жизни — не могу. Будет расценено как нарушение NDA.

M> и надеюсь не очередной велосипед с кривыми колесами и отсутствием покрытия тестами и документации.
Юниттесты имелись. Я кстати к тому же dincumware юниттестов еще не видел никогда. Баги — видел.

M>>>А если кричит что буст это отстой и при этом не строчки не зная и не понимая как это работает
CC>>Аналогично. Если от буста отказались после длительного применения?
M>Пожалуй тут я могу конструктивно пообщаться , в бусте довольно широкий спектр разнообразных библиотек.
У нас отказались после того, как обновление буста, которое требовалось для LUAbind сломало остальной рабочий код до состояния компилится без ошибок но падает в рантайме. Версий уже не вспомню.

M>К сожалению я мало верю в описанный вами сценарий
Дык ваше право

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

	От:	astral_marine
	Дата:	01.08.08 22:23
	Оценка:	16 (6) +2 -3

От:	eao197	http://eao197.blogspot.com
Дата:	01.08.08 13:15
Оценка:	17 (5) +5 -4

	От:	Handie
	Дата:	01.08.08 11:54
	Оценка:	2 (2) +4 -4

	От:	CreatorCray
	Дата:	04.08.08 09:15
	Оценка:	4 (4) +1

От:	eao197	http://eao197.blogspot.com
Дата:	09.08.08 06:06
Оценка:	3 (3) +2

	От:	Roman Odaisky
	Дата:	02.08.08 18:06
	Оценка:	+1

	От:	BulatZiganshin
	Дата:	02.08.08 20:04
	Оценка:	+1

От:	kochetkov.vladimir	https://kochetkov.github.io
Дата:	06.08.08 11:19
Оценка:

От:	Mamut	http://dmitriid.com
Дата:	07.08.08 06:49
Оценка:	+1

	От:	Дм.Григорьев
	Дата:	08.08.08 08:01
	Оценка:

	От:	Евгений Коробко
	Дата:	12.08.08 17:00
	Оценка:	+1

От:	Marty	https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата:	31.07.08 22:33
Оценка:

От:	denisko	http://sdeniskos.blogspot.com/
Дата:	01.08.08 12:38
Оценка:

От:	SergeyT.	http://sergeyteplyakov.blogspot.com/
Дата:	02.08.08 18:37
Оценка:

От:	jazzer	Skype: enerjazzer
Дата:	28.08.08 02:48
Оценка: