Re: [boost] C++17 detection

Subject: Re: [boost] C++17 detection
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-09-12 00:05:19

On 12/09/2017 03:37, Robert Ramey wrote:
> On 9/11/17 8:20 AM, Glen Fernandes wrote:
>> Because we only define things inside std that we are explicitly granted
>> permission to (such as specializations of specific stand library types).
> 
> Right.  But why do "we" do this.  What problem might violating such a 
> permission cause?

You might cause the application to fail to compile correctly when used 
with an unexpected (or newer or older) STL that defines a conflicting 
symbol in that namespace.

If you're the application author, you can get away with that more often, 
as you can change your offending code or perhaps use a different STL or 
different STL version.  You don't have as much freedom as a library author.

>> Yes. You should add BOOST_NO_CXX17_STD_IS_DETECTED or similar to
>> Boost.Config, just as we have added similar C++17 feature detection 
>> macros recently (e.g
>> BOOST_NO_CXX17_FOLD_EXPRESSIONS, for Peter to use in Boost.Mp11).
> 
> Hmmmm - this would require more thought.  My actual interest is the 
> usage o the "detection idiom".  So there should be a
> BOOST_NO_CXX71_DECTECTION_IDIOM ?  Actually that would be ideal for my 
> case.  But it would seem to me that that would be quite a narrow 
> audience to justify the effort.  I'm willing to assume that any library 
> which claims C++17 conformance would support the detection idiom, but I 
> don't find a macro on Boost.Config which lets me know which version of 
> the C++ standard library is supported.  It might be there but I haven't 
> found it.

I'm a little surprised that there doesn't seem to be a Boost.Config 
macro for std::void_t<>; but then there doesn't seem to be many C++17 
macros yet at all.  Perhaps the maintainer is just waiting to see what 
people want to test for, first.

> I guess I'm looking for
> 
> BOOST_C_PLUS_PLUS_LIBRARY_VERSION
> 
> or something like that.

__cplusplus gives you the claimed conformance level of the compiler, 
which is usually (though not necessarily) in agreement with the STL.

But that doesn't do you a lot of good as it's a big catch-all (and at 
least in the case of MSVC lags behind the actual individual feature 
support).  So it's better to test for individual features that you need 
rather than a conformance level as a whole.