[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