On 6/8/2015 10:10 PM, Tim Northover wrote:> On 8 June 2015 at 17:53, Edward Diener <eldlistmailingz at tropicsoft.com> wrote: >> 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.
On Jun 8, 2015 10:53 PM, "Edward Diener" <eldlistmailingz at tropicsoft.com> wrote:> > On 6/8/2015 10:10 PM, Tim Northover wrote: >> >> On 8 June 2015 at 17:53, Edward Diener <eldlistmailingz at tropicsoft.com>wrote:>>> >>> 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 thecorrect 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.> > >> >> 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 headerscan 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.> > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150608/c3cf951e/attachment.html>
On 6/9/2015 12:06 AM, Nathan Wilson wrote:> > On Jun 8, 2015 10:53 PM, "Edward Diener" <eldlistmailingz at tropicsoft.com > <mailto:eldlistmailingz at tropicsoft.com>> wrote: > > > > On 6/8/2015 10:10 PM, Tim Northover wrote: > >> > >> On 8 June 2015 at 17:53, Edward Diener > <eldlistmailingz at tropicsoft.com <mailto:eldlistmailingz at tropicsoft.com>> > wrote: > >>> > >>> 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.> > > > > > >> > >> 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.