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

Subject: Re: [boost] [config] Rethinking feature macros?
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-11-06 01:55:21

On 11/5/2017 8:15 PM, Peter Dimov via Boost wrote:
> Now that there are standard feature-testing macros 
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0096r5.html) 
> that are being implemented by at least g++ and clang++, would it perhaps 
> make sense for us to reevaluate our decision to provide negative macros 
> in Boost.Config and start defining the standard feature macros instead 
> on the compilers that don't support them?
> 
> This would seem to require less maintenance, and the feature macro can 
> be used without waiting for Boost.Config to add it.
> 
> For a concrete example, let's take noexcept in function types. This is 
> __cpp_noexcept_function_type, and is implemented by g++ 7, clang 4, 
> clang 5 (in C++17 mode), and apparently in the latest VS2017 preview.
> 
> noexcept function pointers break Boost.Bind, and to fix it, I need to 
> add overloads for them, but only if they are implemented, otherwise the 
> overloads would be an error.
> 
> With the feature macro, I can just #ifdef __cpp_noexcept_function_type 
> and it will immediately work on g++ and clang++ and all compilers that 
> don't support noexcept function types will still work. Only msvc would 
> need to be fixed in some way.
> 
> With our traditional approach, I would need to request the addition of 
> BOOST_NO_CXX17_NOEXCEPT_FUNCTION_TYPE, wait for it to be added and to be 
> present on every compiler except the latest ones (which requires changes 
> throughout Boost.Config), and only then be able to use #ifndef 
> BOOST_NO_CXX17_NOEXCEPT_FUNCTION_TYPE. (Then wait for it to be merged to 
> master before merging my changes to master.)

I brought up SD-6 for Boost Config some time ago, but the original 
objection was that a great deal of the standard c++ header files would 
have to be included by Boost Config to use most of SD-6. While I see in 
your link that a number of the __cpp_... macros are predefined, like 
your example __cpp_noexcept, a number of other __cpp_... macros require 
header files to be included. So maybe Boost config can use macros which 
are predefined without incurring the header file inclusion overhead of 
those which require a header file to be included to determine if the 
feature is present or not.