Откуда берется негативное отношение к boost?

Откуда берется негативное отношение к boost?

Не замечали такого. У нас только позитивное отношение к boost - это куча готовых рецептов, сокровищница C++, место где можно подумать и поучиться, полигон фич, которые возможно внесут в следующий стандарт языка. В 90% случаев его даже компилировать не надо, хидр онли. А, в связи с его постоянным развитием, в готовых проектах его версия естественно должна фризиться.

А, в связи с его постоянным развитием, в готовых проектах его версия естественно должна фризиться.

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

Так а в чем проблема зафиксировать версию? Ведь все так делают в долгоживущих проектах, ведь делают же? И даже с собой таскают библиотеки и rpath прописывают, и статически линкуют, чтобы достичь одного - должно работать везде.

Кстати, как там переезд прошел с OpenSSL 1.1 на 3.4? Гладко? Ничего не потребовалось пересобирать, обновлять?

Так почему же такая ненависть именно к Бусту?

Мне просто любопытно.

дырки к стандартах

Даже не могу предположить, что за багаж знаний надо иметь, чтобы думать такими категориями… Вероятно, это мировоззрение Arch: «Обновления ради обновлений принося в жертву абсолютно всё». Как вообще кому-то могло прийти в голову включать предкомпилиированные динамические библиотеки буста в репозитарий дистрибутива…

Как вообще кому-то могло прийти в голову включать предкомпилиированные динамические библиотеки буста в репозитарий дистрибутива…

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

Так а в чем проблема зафиксировать версию?

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

• boost всё больше напоминает такое дерьмо как libicu в смысле отсутствия обратной бинарной совместимости библиотек в пределах мажорной версии.
• boost не решает вообще никаких практических задач, это чрезмерно раздутый костыль в попытке устранить косяки всё более раздувающихся новых фич цепепе.
• boost не имеет никакого роадмапа или стратегии развития.

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

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

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

Лечить это надо, а не оправдывать.

Qt, котрый мне нравится гораздо меньше, где все нужно делать как дядя велел

Когда я был в первом классе, ко мне подошел старшеклассник и предложил писать с ним программу на Бейсике. Я стал отказываться, но он меня заставил. С тех пор я пишу программы только на Бейсике. Иногда, когда родители уходят, мы собираемся группой по 6-8 ребят и пишем программы на Бейсике вместе.
Год назад я познакомился с девушкой, и она предложила мне писать программу на Паскале. У меня ничего не вышло: меня стошнило и потом долго болела голова.
Зовут меня Валерий Павлович, в сентябре мне исполнится 47 лет. Моя жизнь сломана.

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

P.S. Против boost ничего не имею.

Вы видно не поняли,

• причем здесь «автор свободного софта»?
• причем здесь адекватные репозитории?

Я говорю про прикладной пакет, который продается за деньги и немалые, и клиентам вот вообще все равно что там внутри. И вот там как раз все прибивается гвоздями, чтобы потом не собирать кучу пакетов под разные версии, например, libsasl2.so.2 или 3…

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

Я говорю про прикладной пакет, который продается за деньги и немалые

Из твоего предыдущего комментария это никак не следует. Писалось про «долгоживущие проекты», они могут быть и проприетарными, и свободными.

Просто такова жизнь - она не ограничивается только «свободным софтом».

В проприетарщине, конечно, можно и версии фиксировать, и многое другое. Но тогда так и пиши, что ты о проприетарщине, там многое делается по-другому. Что-то легче, что-то тяжелее.

Так почему же такая ненависть именно к Бусту?

Ты виртуал ТСа, что ли? «Ненависть» в теме мерещится только одному ему, остальные просто объясняют, почему Буст им не подходит (некоторым, наоборот, подходит – и на здоровье).

Ты виртуал ТСа, что ли? «Ненависть» в теме мерещится только одному ему, остальные просто объясняют, почему Буст им не подходит (некоторым, наоборот, подходит – и на здоровье).

А вот это было неожиданно :)

Софт требует буста из системы, система предоставляет буст через репозиторий, всё.

Буст в дистрибутиве используется пакетами этого дистрибутива, он собран конкретным компилятором и с конкретными настройками, которыми собирались пакеты самого дистрибутива, и только ими. Это вообще не оптимальное решение для ВАШИХ программ.

Это вообще не оптимальное решение для ВАШИХ программ.

А чем, по-твоему, МОИ программы принципиально отличаются от пакетов самого дистрибутива?

А чем, по-твоему, МОИ программы принципиально отличаются от пакетов самого дистрибутива?

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

можно пример таких «экстремальных» C++ участков кода? (и как вообще в принципе сам по себе код может стать причиной несовместимости ABI?)

Известные зарегистрированные/обсуждаемые проблемы с ABI по версии ИИ:

Общие проблемы с C++11 / разными стандартами:

• Многие библиотеки (в т.ч. Asio, System, Thread, Filesystem, Chrono, Regex) имеют ABI-различия между сборками с C++03 и C++11+. Это связано с изменениями в STL (например, std::string), atomic, exceptions и visibility. Boost не предлагает стабильный ABI при смене -std=. Рекомендуется собирать всё (приложение + Boost + зависимости) с одним стандартом. Пример: Boost.Asio часто упоминается как источник проблем при смешении ABI C++03/C++11.

Boost.Function и Boost.Signals (Trac #2256, ~2008):

• Проблемы с non-default alignments (выравниванием). Требовалось включение ABI prefix/suffix headers для корректной работы в проектах с кастомным packing/alignment.

Boost.Interprocess:

• Изменение ABI в rbtree_best_fit (allocator) между 1.53 и 1.55. Это ломало persisted данные в shared memory/mapped files (существующие сегменты памяти становились несовместимы).

Boost.Variant и другие:

• Множественные изменения layout классов в истории (упоминалось с 1.45+). При статическом linking или inline-символах это могло приводить к ODR-нарушениям и крашам при смешении версий.

Boost.Thread:

• Тикеты по прерываниям и ABI-совместимости (например, #13019). Изменения в механизмах interruptions влияли на binary compatibility.

Boost.System и изменения в error_code:

• Изменения ABI между определёнными датами/версиями (упоминалось в 2014). Зависит от флагов компилятора.

Shared libraries и versioning:

• Shared-версии библиотек (например, libboost_program_options.so.1.69.0) строго привязаны к версии. Даже патч-обновления часто ломают binary compatibility без rebuild всего стека.
• Проблемы с _SECURE_SCL в MSVC (изменяет ABI STL-типов и вызывает ODR-violations с Boost).

Другие упоминания:

• Изменения в Boost.Context (assembler/ABI для разных архитектур: aapcs, sysv и т.д.).
• Проблемы с GCC 7+ (обновление ABI namespace).
• В библиотеках вроде MultiIndex, Outcome (зависимости), Locale (взаимодействие с ICU) — косвенные ABI-разрывы.

Политика и практика Boost

• Нет глобальной ABI-стабильности между major/minor релизами. Даже в рамках одного релиза разные build-конфигурации (debug/release, threading, std-версия) могут быть несовместимы.
• Некоторые библиотеки (например, standalone Outcome) вводят собственные гарантии ABI-стабильности с определённой версии, но это исключения.
• В release notes редко явно маркируют «ABI break», но breaking changes в layout классов, добавление/удаление членов, изменения в inline-функциях или visibility часто подразумевают ABI-разрыв.
• Для дистрибутивов (Fedora и др.) обновление Boost требует rebuild всех dependent пакетов именно из-за отсутствия ABI-стабильности.

Рекомендации

• Используйте header-only части где возможно.
• Для shared libs — фиксируйте версию Boost или используйте namespace versioning.
• Избегайте экспонирования Boost-типов в public ABI своих библиотек, если нужна binary compatibility.
• Проверяйте changelog конкретных библиотек и используйте инструменты вроде ABI compliance checker.

ничего не понял — при чём тут ABI и то как «написан код» ? Можно конкретные примеры кода, которые унылят ABI?
Я просто считаю пока что — тут принимается негарантированное за гарантированное, вот и любая опция компилятора может делать с таковым что угодно. И всё соответствует стандарту всё равно.