Почему boost так любит ломать обратную совместимость?

Почему в других библиотеках таких проблем нет

Вангую, вы просто не сталкивались. Это ж линукс.

Буст — это не только Линукс.

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

Вангую, вы просто не сталкивались.

Сталкивался, неоднократно. Но Буст в этом отношении превсошёл всех остальных вместе взятых. Даже с Lua.

Есть другие столь же вопиющие примеры?

Проект bombono-dvd (текущая версия от 2016 года), в АУР поддерживается патчами. Один Два патча для boost и три для ffmpeg

(впрочем, на остальных патчах явно не написана их природа, так что всё возможно…)

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

Начиная с версии 1.82 boost (и его методы) будет требовать -std=c++14

лорчую!

fmt менял abi; sundials (cvodes) при переходе с 3 на 4, с 4 на 5 - сейчас они очень часто обновлять стали версии; catch с версии 3 разделил один заголовочный файл на несколько; откатиться на старый glibc так вообще проблематично; clang 16 много чего скорее всего «поломает».

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

Чтобы сравняться с Бустом, нужно это делать каждый год.

fmt менял abi;

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

sundials (cvodes) при переходе с 3 на 4, с 4 на 5 - сейчас они очень часто обновлять стали версии; catch с версии 3 разделил один заголовочный файл на несколько;

Довольно специфичные вещи, как я понимаю. Такие и от Буста страдают чаще всего :)

откатиться на старый glibc так вообще проблематично;

Это фича :(

Но glibc хотя бы в одну сторону совместима.

clang 16 много чего скорее всего «поломает».

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

Почему в других библиотеках таких проблем нет, а в Бусте есть?

Потому что

development is continuous and at a rapid pace, never
stopping to slow down. As such, the .... developers find bugs in
current interfaces, or figure out a better way to do things. If they do
that, they then fix the current interfaces to work better. When they do
so, function names may change, structures may grow or shrink, and
function parameters may be reworked

Первые года 3 на нынешнем месте работы половину рабочего времени я вылавливал баги в сторонних библиотеках, зависевших от Буста. Мы регулярно их обновляли, менялись версии в boost*.dll, старые баги исчезали, появлялись новые…

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

это то, что происходит почти с любым опенсорсом: модули для пхп, пипона, руби, maven/gradle постоянно инкременируют версии и периодически ломают обратную совместимость, в результате через 2-3 года ничего уже не соберешь и не установишь в систему. Когда люди перестали обновляться они сломали протоколы типа HTTP и SSL, FTP выбросили, SMTP огородили. Сейчас компьютер 10и летней давности просто не выйдет в интернеты.

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

Всё было закрытое, мы просто получали пачку новых DLL.

Есть другие столь же вопиющие примеры?

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

Header-only library, говорили они.

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

Всё было закрытое, мы просто получали пачку новых DLL.

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

Header-only library, говорили они.

Даже если бы оно было header-only library, оставались бы проблемы с глобальными символами, если разные so-шки собраны с разными версиями библиотеки. Синглтоны всякие, rtti об исключениях, и тд. Ну и очевидные проблемы с abi, если структуры из header-only library участвуют непосредственно в сигнатурах экспортируемых функций so-шки.

Другого Питона у меня для вас нет (с)

Стейбл апи это миф :) Констант онли чейнжес.

Под WinAPI можно и сейчас писать. Тяжело и муторно, но можно

Почему boost так любит ломать обратную совместимость?

Многие проблемы в разработке возникают от «Горе от ума».

Лучше так, чем сраный PIMPL.

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

Помимо перехода 2 → 3 (который, да, убил несколько важных программ) что-нибудь сопоставимое по разрушительности было?

Постоянно что-нибудь, да отвалится

Header-only library, говорили они.

Разве Буст header-only?

Ну сам и пиши под этот свой винапи :)

Постоянно что-нибудь, да отвалится

Угу!

В воскресенье стук в дверь и крики «Вы нас топите».
Что сделал?

Поменял всю сантехнику.

Helloworld? Это я могу!

Уже точно нет.

Потому что буст не нужен.

Ок, винапи для хеллуворлдов, ножы и анстейбл апи выбор мастеров :)

Всё так

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

Почему в других библиотеках таких проблем нет, а в Бусте есть?

Такие проблемы везде есть, просто частота их появления зависит от площади API, его низкоуровневости, ну и темпов развития библиотеки.

Линкуй статически. Даже libstdc++ ломают ABI в зависимости от версии стандарта, что уж говорить про boost. Обычно ABI соблюдают только либы с чистым C API.

Эту проблему native ABI vs «Syntax Sugar API» решили только Apple в своих Swift интерфейсах.

Нет, но не-ho библиотек в нем немного.

А проблема в чем?

В невозможности собирать слегка подзаброшенные программы.

или как в дебиане - говно мамонта, но прочное как скала

или как в роллинге - все самое свежее, но временами (часто) не работает

а других моделей доставки у нас для вас нет.

Ну а я о чем? Собирай со старыми версиями.

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

I know that feel bro.

error: 'recursive_directory_iterator' is deprecated: Use directory_options instead of symlink_option [-Werror,-Wdeprecated-declarations]
        for ( fs::recursive_directory_iterator itr( dirpath, opt ); itr != end_itr; ++itr )
                                               ^
/usr/include/boost/filesystem/directory.hpp:576:5: note: 'recursive_directory_iterator' has been explicitly marked deprecated here
    BOOST_FILESYSTEM_DETAIL_DEPRECATED("Use directory_options instead of symlink_option")
    ^
/usr/include/boost/filesystem/config.hpp:85:64: note: expanded from macro 'BOOST_FILESYSTEM_DETAIL_DEPRECATED'
#define BOOST_FILESYSTEM_DETAIL_DEPRECATED(msg) __attribute__((deprecated(msg)))

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

Почему в других библиотеках таких проблем нет

Лол ну да, почти