C++ Logo

SG10

Advanced search

Subject: Re: [SG10] First draft recommendation for C++14
From: Richard Smith (richard_at_[hidden])
Date: 2013-05-06 13:17:26


On Sat, May 4, 2013 at 8:08 PM, Nelson, Clark <clark.nelson_at_[hidden]>wrote:

> > > Which of these is the behavior we want for these feature-test macros?
> > In my experience, __has_feature(X) is what you want when determining
> > whether to use a language feature in normal code, but __has_extension(X)
> > is what you want when determining whether to use a language feature in a
> > system header.
> >
> > FWIW, I have always taken the view that, when an implementer implements
> > a feature, he should define the macro.
>
> I hit "Send" a little too fast on this one. I should have said something
> more like, "When an implementer implements a feature, he should arrange for
> the macro to be defined in the same circumstances under which he supports
> the feature." -- for example, under the control of the same command-line
> option(s).
>

The real world (at least for Clang, and as far as I can tell, for g++ and
EDG too) is more nuanced than that. We have three states for a feature: (1)
not available, (2) available as an extension (with a warning, or an error
in -pedantic-errors mode or -Werror mode), and (3) available as part of the
enabled language mode (with no warning/error).

__has_extension expands to 1 for (2) and (3), which doesn't work reliably
outside of system headers and __extension__ regions, because you might be
building with -pedantic-errors or -Werror or something else which causes a
use of the extension to be rejected. __has_feature doesn't have that
problem, but only expands to 1 for (3).



SG10 list run by herb.sutter at gmail.com