Subject: Re: [boost] [config] Rethinking feature macros?
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-11-06 13:22:31
On 11/6/2017 7:45 AM, Peter Dimov via Boost wrote:
> 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
This is a better idea, if only to align Boost Config macro names with
the SD-6 macros.
> 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.)
Theoretically a good idea, but we then end up with defining Boost
equivalent SD-6 macros, where the compiler macros are based on SD-6 and
the library macros are based on Boost Config logic.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk