Дмитрий Архипов wrote:
чт, 4 сент. 2025 г. в 20:16, Matt Gruenke via Boost <boost@lists.boost.org>:
I don't know about any official policy on the matter, but I and others have previously gotten burned by having it be a compile-time check at the point of inclusion. I feel strongly that the proper solution is to rely on Boost Config, so that everything compiling against a build of Boost will compile in the same way and thereby avoid any ODR violations.
This doesn't solve the issue, it just pushes the problem to link time. E.g. you build Boost in a configuration that doesn't have std::optional, then you link to it in a configuration that does. This is actually trivially done by accident (e.g. you build Boost with a compiler that defaults to C++14, then you use it with C++17 enabled). For header-only libraries the problem also exists, it's just pushed into users' libraries.
The least surprising way to do this is to ask users to explicitly enable standard equivalents. This still has the same problem fundamentally (nothing prevents users from defining the macro when building Boost and not defining it when using it, or vice versa). But because it requires actions from users it should significantly decrease the chances of it happening, and if it does happen, the reason should be more obvious to them.
Note that because these problems occur nevertheless, Boost.JSON has removed the option to switch to std::error_code and std::pmr.
Basically, the only reliable solution is to just require C++17 in the library and use the standard components unconditionally (or not require it and use the Boost components unconditionally.) In some cases, e.g. when using boost::system::error_code or boost::core::string_view, this still allows use with std::error_code or std::string_view because the Boost components interoperate with the standard ones. I think that most libraries can afford to require C++17 today and avoid the hassle. C++17 is default on GCC 11 and Clang 13. It's too bad that the sweet spot for the language is C++14 and for the library C++17, but, well.