Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk