Subject: Re: [boost] [config] Rethinking feature macros?
From: Peter Dimov (lists_at_[hidden])
Date: 2017-11-06 02:30:22
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
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 <boost/config.hpp>. 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...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk