[cfe-dev] Testing for libc++ version number

[Edward Diener]

On 6/9/2015 2:21 PM, Richard Smith wrote:
> On Tue, Jun 9, 2015 at 10:34 AM, Edward Diener
> <eldlistmailingz at tropicsoft.com
> <mailto:eldlistmailingz at tropicsoft.com>> wrote:
>
>     On 6/9/2015 11:16 AM, Marshall Clow wrote:
>
>         On Tue, Jun 9, 2015 at 6:03 AM, Edward Diener
>         <eldlistmailingz at tropicsoft.com
>         <mailto:eldlistmailingz at tropicsoft.com>
>         <mailto:eldlistmailingz at tropicsoft.com
>         <mailto:eldlistmailingz at tropicsoft.com>>>
>         wrote:
>
>              On the libc++ C++1Y Status web page, at
>         http://libcxx.llvm.org/cxx1y_status.html
>         <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=>
>
>         <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=>,
>              it mentions at what first released version a particular C++1Y
>              feature has been implemented for libc++.
>
>
>         No, that's the release of LLVM where it first appeared.
>
>              Is this the _LIBCPP_VERSION macro ? If so what is the
>         format of this
>              macro, so I can test its value ? If it is not the
>         _LIBCPP_VERSION
>              macro what value is it and how can I test for it at compile
>         time ?
>
>
>         The  _LIBCPP_VERSION macro changes when a breaking changed is
>         made to
>         libc++.
>         So far, there have not been any. (or, at least, any major ones).
>
>         We've had discussions about having a version number for libc++, but
>         that's all they've been ... discussions.
>
>
>     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.
>
>     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.
>
>
> What about this:
>
> #ifdef __has_include
> #if __has_include(<shared_mutex>)
> #define HAS_SHARED_MUTEX
> #endif
> #endif
>
> 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?

Naturally I want the test to be as accurate as it can be.

Actually gcc 4.9 and up does ship with shared_mutex and using only your 
test above, since gcc doesn't support SD-6 until gcc 5.1 I believe, 
would tell me that shared_mutex is not supported in gcc 4.9.n.

>
> 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.

Unfortunately if compilers do not support SD-6 I have to come up with 
some fallback way. If libc++ already had a built-in way I could have 
used that but I accept that there never has been such a mechanism. I 
think it should have had its own mechanism from the beginning, but given 
that it did not, and with the advent of SD-6. I agree that SD-6  the 
right solution. I will implement that and fallback to other  solutions, 
including what is already being used in boost/config/stdlib/libcpp.hpp ( 
testing __cplusplus ).