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

J>Просто о бусте бытует следующее представление:
J>1. Буст исключительно сложный
J>2. Некоторые библиотеки типа boost::mpl — с ними вообще простым смертным не разобраться
J>3. Чтобы использовать буст, надо вначале написать кучу трехэтажных шаблонов (особенно в случае boost::mpl), и как только ты их используешь, твой обычный код, который был бы без буста очень простым и коротким, теперь всегда будет горой шаблонов, текста будет в разы больше, и в основном нечитабельного.
J>4. Буст и особенно такие его части, как boost::mpl, простым прикладным программистам не нужны, они нужны только разработчикам библиотек.

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

Так вот у меня совсем другой список претензий к boost-у:

1. Реализация boost-а исключительно сложна. Ну т.е., когда все идет гладко и в исходники библиотеки заглядывать не нужно, то нет проблем. Но, тем не менее, здесь есть два момента, которые мне не нравятся:
— ни в одном другом языке (а мне приходилось лазить в библиотеки Ruby, Eiffel, D, немного Java) мне не приходилось видеть такой разительной разницы в сложности реализации библиотек и прикладных приложений. По мне, это некий признак того, что что-то где-то не так;
— всегда приятно иметь увереность в том, что твоих знаний хватает для того, чтобы при необходимости разобраться в деталях с происходящим в твоем приложении. По крайней мере у меня не было проблем с тем, чтобы залезть во внутренности MFC, Qt, FOX, ACE. В случае с boost ситуация обратная -- тот же boost.variant сразу же отбивает желание понять, как же он устроен.

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

3. Некоторые библиотеки boost-а (тот же boost.lambda, а так же boost.spirit), на мой взгляд, являются примерами того, что не нужно делать. При этом у меня складывается впечатление, что наличие подобных вещей создает у C++программистов "головокружение от успехов" -- т.е. программирование на шаблонах в C++ становится модным направлением. Именно "модным", когда шаблоны применяются и к месту, и не к месту.

4. Boost велик. Слишком велик. 22Mb в tar.bz2 версии 1.35 -- это занадто. Имхо, для C++ поздно создавать одну большую стандартную библиотеку. Можно понять Sun с JDK и MS с .NET Framework, которые держат большие штаты программистов, поддерживающих JDK/.NET Framework. А кто будет поддерживать OpenSource-ный boost? Что произойдет, если кому-то из авторов включенных в boost библиотек надоест сопровождать и развивать свое творение? Или как разработчикам каких-то библиотек выпускать новые релизы вне графика выхода версий самого boost-а?

Далее, включение библиотеки в boost осуществляется по результатам review, в которых, обычно, едва набирается несколько десятков отзывов. Т.е. заявляется что-нибудь типа boost.egg

Автор: Ka3a4oK
Дата: 03.04.08

и что? Находятся несколько ценителей прекрасного, которые присылают положительные review и egg в boost-е. И что из того, ценность буста повысилась? В то же время вне буста есть, например, crypto++, botan или cryptlib, которыми пользуются сотни, если не тысячи программистов, но которые никаким боком к boost-у не относятся.

Еще один момент. Библиотеки, которые являются альтернативными boost-овским, они что, уже второго сорта? Бустовская сериализация -- она лучше, чем s11n? Бустовские регулярные выражения лучше, чем PCRE? Бустовские юнит-тесты намного лучше CppUnit? Не получится ли так, что когда разработчику понадобиться что-то, то он просто возмет реализацию из boost-а даже не глядя на альтернативы? Т.е. выбор будет строится не на возможностях, а на репутации. Как бы в результате boost не стал монополистом, который своей массой будет просто давить конкурентов.


Вот такое, собственно говоря, имхо.
Не то, чтобы я принципиально отказывался от использования boost-а по каким-то религиозным соображениям. У меня даже часть старых проектов использует boost.unit для юнит-тестов. Или если мне потребуется boost.multi_index, то я возьму boost. Но сделаю это несколько скрепя сердцем, поскольку boost просто не является библиотекой, которая мне нравится (в отличии, например, от PCRE, Qt, FOX, ACE, Crypto++ и иже с ними).

К читателям: не думаю, что нужно начитать флейм по этому поводу. Я описал весь этот текст для того, чтобы у jazzer-а не сложилось превратного впечатления о том, в чем же я лично обвиняю boost.