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

[Richard Smith]

On Tue, Jun 9, 2015 at 10:34 AM, Edward Diener <
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>> 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=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?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150609/91f18765/attachment.html>