C++14 support for shared_mutex

How can I tell at compile time through predefined macros whether libc++ includes/supports the C++14 header file shared_mutex ?

Given that I have identified that libc++ is being used, will this work ? :

#if __cplusplus >= 201402
// Header file shared_mutex supported
#endif

or do I need to check something else ?

The most reliable way would be to get your build system to try to compile source code which includes <shared_mutex> and then instantiates shared_mutex<> with a plausible type. Anything else would be pretty speculative as C++17 isn’t even finished yet and it is possible, although pretty unlikely IMO, for the feature to be removed.

I doubt it's even theoretically possible. Clang can be used with
multiple standard libraries, and there's no real way for it to know
just what you're compiling against (even if it knows in general terms
that it's libc++).

On a tightly controlled platform like OS X you might find a mostly
reliable proxy like the clang version (though people trying to use an
updated libc++ may curse you for it).

Cheers.

Tim.

How can I tell at compile time through predefined macros whether libc++
includes/supports the C++14 header file shared_mutex ?

I doubt it's even theoretically possible. Clang can be used with
multiple standard libraries, and there's no real way for it to know
just what you're compiling against (even if it knows in general terms
that it's libc++).

I am not talking about clang, I am talking about libc++. Is this the correct mailing list to ask a question about libc++ or is there a better one ? I did not see a separate llvm mailing list for libc++.

On a tightly controlled platform like OS X you might find a mostly
reliable proxy like the clang version (though people trying to use an
updated libc++ may curse you for it).

I can tell "in general terms that it's libc++". The Boost.config headers can know that from the macro _LIBCPP_VERSION. Once I can tell, you are saying that there is no reliable way to tell whether libc++ supports shared_mutex, which is currently a completely valid C++14 header file and implementation ? That seems pretty poor of libc++. I don't mean to be critical but I think that a good standard library creates predefined values so that what can tell what is being offered in that library for any given release. You can't wait until run-time to include a header which may not be there.

I don't want to check anything in clang because, as I understand it, libc++ can be and is being used by compilers other than clang. So I would assume that either _LIBCPP_VERSION or some other macro connected with libc++ should tell me at compile time if shared_mutex is supported.

How can I tell at compile time through predefined macros whether libc++
includes/supports the C++14 header file shared_mutex ?

I doubt it’s even theoretically possible. Clang can be used with
multiple standard libraries, and there’s no real way for it to know
just what you’re compiling against (even if it knows in general terms
that it’s libc++).

I am not talking about clang, I am talking about libc++. Is this the correct mailing list to ask a question about libc++ or is there a better one ? I did not see a separate llvm mailing list for libc++.

I see Marshall’s commits and review requests directed toward the cfe-dev list with libcxx in the subject. So, you loop them in or try that mailing list.

How can I tell at compile time through predefined macros whether libc++
includes/supports the C++14 header file shared_mutex ?

If you just want to see whether the header exists, and are using Clang or GCC 5, you can use __has_include:

http://clang.llvm.org/docs/LanguageExtensions.html#include-file-checking-macros

>
>>
>>>
>>> How can I tell at compile time through predefined macros whether libc++
>>> includes/supports the C++14 header file shared_mutex ?
>>
>> I doubt it's even theoretically possible. Clang can be used with
>> multiple standard libraries, and there's no real way for it to know
>> just what you're compiling against (even if it knows in general terms
>> that it's libc++).
>
> I am not talking about clang, I am talking about libc++. Is this the
correct mailing list to ask a question about libc++ or is there a better
one ? I did not see a separate llvm mailing list for libc++.

I see Marshall's commits and review requests directed toward the cfe-dev
list with libcxx in the subject. So, you loop them in or try that
mailing list.

I will try the clang developers mailing list.

    How can I tell at compile time through predefined macros whether libc++
    includes/supports the C++14 header file shared_mutex ?

If you just want to see whether the header exists, and are using Clang
or GCC 5, you can use __has_include:

Clang Language Extensions — Clang 16.0.0git documentation
<https://urldefense.proofpoint.com/v2/url?u=http-3A__clang.llvm.org_docs_LanguageExtensions.html-23include-2Dfile-2Dchecking-2Dmacros&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=OBReYKDPkf2rIiHX9dCaocBlBS1aWqjyHfv96KXGjfE&s=yjq9jFWbl69Ob-COO8Wa4Pjq1ERvEIh_s0BHGssfbr0&e=&gt;

Amusingly I see a shared_mutex header file for gcc 4.9. But I would need GCC 5 to tell me it exists using the include file checking macros at compile time. And which version of clang would I need to use that facility ?

Shouldn't this be a libc++ problem to solve ? After all the potential shared_mutex can be or not be part of libc++, and libc++ was designed, was it not, to be potentially used by any compiler. So relying on a particular compiler to tell me what libc++ should be telling me, seems not a good design.

I notice libc++ has a _LIBCPP_VERSION macro. Couldn't libc++ at least document somewhere that for any given version _LIBCPP_VERSION it supports some given list of libraries ? That would be sensible in my mind. Then what it supports is independent of the compiler which uses it.

(Copy of a part of a response I posted on cfe-dev)

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