чт, 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.