Steven Watanabe wrote:
I think it's probably a bad idea for Boost.Config to try to define the standard feature macros.
- #defining third-party macros in library code is a recipe for ODR violations.
There is no difference between defining __cpp_foo and BOOST_NO_CXX17_FOO as far as ODR violations are concerned. In both cases, before the inclusion of boost/config.hpp the macro isn't set, and after the inclusion, it may be.
- It's easy for those using compilers with support for these macros to forget to #include
. There's also a good chance that the automated tests will pass for compilers without such support in this case, as it's quite common for the fallback implementation to work even if the feature is actually present. (Or the corresponding tests might just end up being disabled as well.)
This is unfortunately a good point, and this new approach is indeed more fragile than the old one WRT forgetting to include boost/config.hpp. But on the other hand, the old one suffers from the problems I outlined. Ideally, MSFT would be persuaded to implement the macros, but until then...