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.
# define BOOST_CPP_NOEXCEPT_FUNCTION_TYPE
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.)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk