Am 10.09.25 um 20:34 schrieb Matt Gruenke via Boost:
Дмитрий Архипов 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. I think it's reasonable to expect people to compile, link, and run against the same build of Boost. You could still have an independently compiled Boost with C++11, a dependency using Boost compiled with C++14 and your own library using C++17 causing potentially 3 different "contents" of the Boost headers. I'm fine with a link-time error as the alternative would be an ODR-violation so detecting it at compile/linktime is better. 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). This illustrates perfectly why it should not be a compile-time check, at the point of inclusion. The Boost Config headers are generated when boost, itself, is compiled. When a precompiled build of boost is installed, the config headers come with it. The config headers are not generated (yet). They are kept as-is during installation and just contain a set of macros to enable disable stuff based on current compiler and flags. Or are you proposing that Boost config headers *should* be generated? The least surprising way to do this is to ask users to explicitly enable standard equivalents. This fundamentally doesn't work, when the header you're including is also included and used by code in one or more of the non- header-only boost libraries you're linking against. That's how you get ODR violations. Or by code of dependencies. Even header-only dependencies could cause issues when you define BOOST_X=1 but one of the dependencies headers defines BOOST_X=2 and you might have different TU where one does include that dependency header and one that does not. The definition of types must be consistent by all code which includes them and might be linked into the same executable or library. That's why Boost.Config is the correct solution to this problem, to the extent it's not simply a hard-wired requirement of the library. What is meant by the last sentence? Peter Dimov avoids the problem by essentially doing away with any choice. That also works, so long as everyone can agree on the minimum version requirement. "minimum version" of what? E.g. you'd actually need to agree on a specific C++ version and use that for the whole compilation including Boost and potentially other dependencies using Boost.