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.