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