On Sat, May 4, 2013 at 8:08 PM, Nelson, Clark <span dir="ltr"><<a href="mailto:clark.nelson@intel.com" target="_blank">clark.nelson@intel.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> > Which of these is the behavior we want for these feature-test macros?<br>
> In my experience, __has_feature(X) is what you want when determining<br>
> whether to use a language feature in normal code, but __has_extension(X)<br>
> is what you want when determining whether to use a language feature in a<br>
> system header.<br>
><br>
> FWIW, I have always taken the view that, when an implementer implements<br>
> a feature, he should define the macro.<br>
<br>
</div>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).<br>
</blockquote><div><br></div><div>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).</div>
<div><br></div><div>__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).</div>
</div>