On Sat, May 4, 2013 at 8:08 PM, Nelson, Clark <span dir="ltr">&lt;<a href="mailto:clark.nelson@intel.com" target="_blank">clark.nelson@intel.com</a>&gt;</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">&gt; &gt; Which of these is the behavior we want for these feature-test macros?<br>
&gt; In my experience, __has_feature(X) is what you want when determining<br>
&gt; whether to use a language feature in normal code, but __has_extension(X)<br>
&gt; is what you want when determining whether to use a language feature in a<br>
&gt; system header.<br>
&gt;<br>
&gt; FWIW, I have always taken the view that, when an implementer implements<br>
&gt; a feature, he should define the macro.<br>
<br>
</div>I hit &quot;Send&quot; a little too fast on this one. I should have said something more like, &quot;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.&quot; -- 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&#39;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&#39;t have that problem, but only expands to 1 for (3).</div>
</div>