<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 10, 2013, at 8:25 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Tue, May 7, 2013 at 1:00 PM, John Spicer <span dir="ltr"><<a href="mailto:jhs@edg.com" target="_blank">jhs@edg.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">
I'm not personally fond of that direction.<br>
<br>
At least for EDG, and I suspect others, the set of feature supported is going to depend on command-line options, which would mean that we'd have to define one set of macros (or something) to allow the <features> header to define another set. It also makes it more likely that you could have a <features> file that doesn't actually match what the compiler does.<br>
</blockquote><div><br></div><div>Since our names are reserved identifier, an implementation can predefine them and provide a <features> which does nothing.</div><div><br></div><div>This allows feature test macros to be provided (a) with no compiler changes, (b) retroactively for an implementation which was released prior to our recommendations (provide a <features> which checks the compiler and version, and use -D__cpp_lib_header_features), and (c) with (essentially) zero cost for programs which do not use the macros. This also happens to be standardizing existing practice ;-)</div>
<div><br></div><div>That said, I agree with Clark that quantifying the cost in (c) would be useful. I have informally heard that this cost is measurable (especially for things like configure scripts which build a large number of tiny programs), but I've never seen numbers.</div></div></blockquote><div><br></div><div>I don't have a problem with requiring an include of <features> in order to access feature macros.</div><div><br></div><div>I would hope, however, that compiler vendors would either recognize that header and then predefine the appropriate macros or have the file contain something like</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>#pragma define_feature_macros</div><div><br></div><div>What I would not like to see, which is actually what existing practice is, is a file that said something like:</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>#if defined(__GNUC__) && __GNUC__ >= <something> && __GNUC_MINOR__ >= <something></div><div><span class="Apple-tab-span" style="white-space:pre">        </span> #define __cpp_has_xxx <something></div><div><span class="Apple-tab-span" style="white-space:pre">        </span> #define __cpp_has_xxx <something></div><div><span class="Apple-tab-span" style="white-space: pre; ">        </span>#elif defined(_MSC_VER) && ...</div><div><span class="Apple-tab-span" style="white-space:pre">        </span> #define __cpp_has_xxx <something></div><div><span class="Apple-tab-span" style="white-space:pre">        </span> #define __cpp_has_xxx <something></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>... etc ...</div><div><br></div><div>So, I agree that this has the advantage of providing a bridge that can be used with implementations released prior to specifying the feature macros, and also has the advantage of having zero cost unless they are used.</div><div><br></div><div>But I think to most effectively address the issue, compiler support is required.</div><div><br></div><div>To quote an example that Clark provided:</div><div><br></div><div><pre>#ifndef __USE_RVALUE_REFERENCES
#if (__GNUC__ > 4 || __GNUC__ == 4 && __GNUC_MINOR__ >= 3) || \
_MSC_VER >= 1600
#if __EDG_VERSION__ > 0
#define __USE_RVALUE_REFERENCES (__EDG_VERSION__ >= 410)
#else
#define __USE_RVALUE_REFERENCES 1
#endif
#elif __clang__
#define __USE_RVALUE_REFERENCES __has_feature(cxx_rvalue_references)
#else
#define __USE_RVALUE_REFERENCES 0
#endif
#endif</pre><div><br></div><div><br></div><div>My hope is that our recommendations will eliminate the need for heuristics and rely on a definitive answer from the compiler.</div><div><br></div><div>John.</div></div><div><br></div><blockquote type="cite"><div class="gmail_quote">
<div> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">
John.<br>
<div><div class="h5"><br>
On May 7, 2013, at 3:17 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> Has any thought been given to putting the feature-test macros into an implementation-supplied header, instead of predefining them? This would allow us to remove the cost associated with predefining these macros, for translation units which don't need them. Instead, we could supply a single predefined macro indicating whether the header is available, and user code would write something like:<br>
><br>
> #ifdef __cpp_lib_header_features<br>
> #include <features><br>
> #endif<br>
><br>
> #ifdef __cpp_relaxed_constexpr<br>
> constexpr<br>
> #endif<br>
> size_t strlen(const char *p) { /* ... */ }<br>
><br>
> ... and so on.<br>
</div></div>> _______________________________________________<br>
> Features mailing list<br>
> <a href="mailto:Features@isocpp.open-std.org">Features@isocpp.open-std.org</a><br>
> <a href="http://www.open-std.org/mailman/listinfo/features" target="_blank">http://www.open-std.org/mailman/listinfo/features</a><br>
<br>
</blockquote></div><br>
_______________________________________________<br>Features mailing list<br><a href="mailto:Features@isocpp.open-std.org">Features@isocpp.open-std.org</a><br>http://www.open-std.org/mailman/listinfo/features<br></blockquote></div><br></body></html>