On Sat, May 4, 2013 at 8:08 PM, Nelson, Clark <clark.nelson@intel.com> 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).