[cfe-dev] Testing for libc++ version number
richard at metafoo.co.uk
Tue Jun 9 11:21:13 PDT 2015
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
>> 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
>> 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:
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...
More information about the cfe-dev