Re: [boost] [config] Rethinking feature macros?

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 
> 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 <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...