Testing for libc++ version number

On the libc++ C++1Y Status web page, at http://libcxx.llvm.org/cxx1y_status.html, it mentions at what first released version a particular C++1Y feature has been implemented for libc++. 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 ?

On the libc++ C++1Y Status web page, at
http://libcxx.llvm.org/cxx1y_status.html, 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.

-- Marshall

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.

        On Tue, Jun 9, 2015 at 6:03 AM, Edward Diener
        <eldlistmailingz@tropicsoft.com
        <mailto:eldlistmailingz@tropicsoft.com>
        <mailto:eldlistmailingz@tropicsoft.com
        <mailto:eldlistmailingz@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

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