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

Subject: Re: [boost] [config] Rethinking feature macros?
From: Peter Dimov (lists_at_[hidden])
Date: 2017-11-06 12:45:02

Andrey Semashev wrote:

> Besides, I believe this is not Boost's prerogative to define compiler and 
> standard library-specific macros.

Steven made the same good point - we should not define these macros because 
someone else may decide to do it too.

> Boost.Config macros do not necessarilly correspond to what the compiler 
> defines. Compilers lie sometimes by defining a macro while the 
> corresponding feature is broken.

That's true in principle but I've found this practice questionable and can't 
help but note that in my specific example of __cpp_noexcept_function_type, 
if Config doesn't define the macro my code will break, regardless of whether 
the feature is broken. I want to know if the feature is present, not whether 
someone arbitrarily considers it broken. But that's really a side issue.

> Also, on the std-proposals list (IIRC) there was a discussion about SD-6 
> macros, and there were even initiatives to entirely drop the whole idea.

I don't remember a time when this wasn't the case.

The objections to the specific idea of defining SD-6 macros in Config are 
solid, but nobody has said anything about the inefficiencies in our current 
approach that are caused by us defining negative macros instead of positive 
ones. We can avoid the problem of not being allowed to define "foreign" 
macros by having our own names for them and defining them automatically when 
the standard macro is defined.

#ifdef __cpp_noexcept_function_type
# define BOOST_CPP_NOEXCEPT_FUNCTION_TYPE
#endif

Positive macros suffer from the problem of one forgetting to include 
config.hpp a bit more than negative macros do, but using our names avoids 
the other problem Steven brings up, that things would silently work in this 
case on g++/clang++.

(Of course the above doesn't work for library macros because we don't want 
to include the whole STL but we still can use positive macros there, we just 
need to define them ourselves appropriately.)