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

Edward Diener eldlistmailingz at tropicsoft.com
Tue Jun 9 10:34:30 PDT 2015


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.




More information about the cfe-dev mailing list