<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jun 9, 2015 at 10:34 AM, Edward Diener <span dir="ltr"><<a href="mailto:eldlistmailingz@tropicsoft.com" target="_blank">eldlistmailingz@tropicsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 6/9/2015 11:16 AM, Marshall Clow wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On Tue, Jun 9, 2015 at 6:03 AM, Edward Diener<br>
<<a href="mailto:eldlistmailingz@tropicsoft.com" target="_blank">eldlistmailingz@tropicsoft.com</a><br></span><span class="">
<mailto:<a href="mailto:eldlistmailingz@tropicsoft.com" target="_blank">eldlistmailingz@tropicsoft.com</a>>> wrote:<br>
<br>
    On the libc++ C++1Y Status web page, at<br>
    <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__libcxx.llvm.org_cxx1y-5Fstatus.html&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=KsqutJkKhl_V0wWnQ51_vNdnhe-RsBisvV8dDX2-exg&s=jFQUUqRUKmcu9yRbqMrHjBb5DRDHwOY5wW4jEaxLxps&e=" target="_blank">http://libcxx.llvm.org/cxx1y_status.html</a><br></span>
    <<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__libcxx.llvm.org_cxx1y-5Fstatus.html&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=OWq297VZ6Kqncya-rex8mu2w14RLcEdqluRH56qmiZE&s=od7L4EUkTRZPs_wADurBaHP9WAu5yUI4jTySxByCZA4&e=" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__libcxx.llvm.org_cxx1y-5Fstatus.html&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=OWq297VZ6Kqncya-rex8mu2w14RLcEdqluRH56qmiZE&s=od7L4EUkTRZPs_wADurBaHP9WAu5yUI4jTySxByCZA4&e=</a>>,<span class=""><br>
    it mentions at what first released version a particular C++1Y<br>
    feature has been implemented for libc++.<br>
<br>
<br>
No, that's the release of LLVM where it first appeared.<br>
<br>
    Is this the _LIBCPP_VERSION macro ? If so what is the format of this<br>
    macro, so I can test its value ? If it is not the _LIBCPP_VERSION<br>
    macro what value is it and how can I test for it at compile time ?<br>
<br>
<br>
The  _LIBCPP_VERSION macro changes when a breaking changed is made to<br>
libc++.<br>
So far, there have not been any. (or, at least, any major ones).<br>
<br>
We've had discussions about having a version number for libc++, but<br>
that's all they've been ... discussions.<br>
</span></blockquote>
<br>
Thanks Marshall. I have actually been trying to add information to Boost.config's boost/config/stdlib/libcpp.hpp file to determine if libc++ supports the C++ 14 shared_mutex library. I can see that the libc++ C++1y compliance web page says it does starting with llvm 3.4, but considering that libc++ could be used outside of llvm/clang that does me little good unless libc++ itself can encode version information in the form of its own macro. Of course if libc++ developers absolutely don't foresee libc++ being used outside of clang then it is not their concern but my understanding seems to be that libc++ was designed for any compiler to use, and not just clang. If the latter is indeed the case it behooves libc++ developers to encode some scheme by which a programmer can know what C++ standard libraries a particular release of libc++ supports at compile time.<br>
<br>
I can of course continue to do what the boost/config/stdlib/libcpp.hpp header file currently does, which is to look at the __cplusplus number for the compiler which is using libc++, and decide from there and no doubt empirical experiment if shared_mutex is supported. And I can look to see if the compiler is clang and if clang is version 3.4 or above know that shared_mutex is supported. But a means by which libc++ encodes information itself about what C++ standard libraries are supported, even if it means just encoding the llvm/clang release in its own macro, and relying on programmers to look at its website conformance pages, would be much better.</blockquote><div><br></div><div>What about this:</div><div><br></div><div>#ifdef __has_include</div><div>#if __has_include(<shared_mutex>)</div><div>#define HAS_SHARED_MUTEX</div><div>#endif</div><div>#endif </div><div><br></div><div>It'll return a conservatively-correct answer (no <shared_mutex>) for GCC 4.x and other compilers that don't implement SD-6's recommendations; how accurate do you need this test to be?</div><div><br></div><div>Given the existence of SD-6, I don't think that libc++ should add its own mechanisms for feature-testing going forward -- we should try to avoid making more mess while the world catches up.</div></div></div></div>