Re: [boost] [config] Using SD-6 macros

Subject: Re: [boost] [config] Using SD-6 macros
From: John Maddock (jz.maddock_at_[hidden])
Date: 2015-06-13 04:12:13

> Each particular check does not include the whole std lib. Are you 
> really objecting to including individual headers for individual 
> features if there is no absolutely reliable method otherwise ?
>
Well the question is "is there a reliable method otherwise"?  There may 
well not be for clang/libstdc++ but for everything else I'm fairly sure 
there is.

BTW this is not my objection so much as I can tell you from past 
experience that users absolutely do complain if Boost.Config starts 
#including too much.  Were we to duplicate all the SD6 macros then we 
would have to include all of:

utility
memory
functional
type_traits
chrono
string
map
set
iterator
algorithm
complex
iomanip
shared_mutex

Are you suggesting that would be a good idea for a library that just 
wants to check if |BOOST_NO_LONG_LONG is set?

There are obviously other solutions - separate headers for this stuff 
for example - but we're not there yet - remember that we only tend to 
add new macros when libraries actually need them, not as vaporware.
|
> So we let each Boost library and each end-user of Boost go through the 
> mechanism of checking a C++14 feature using SD-6 themselves rather 
> than doing it once in Boost.config ?
>
There's little difference:

#ifdef |__cpp_lib_integer_sequence 
<https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations#detail.cpp14.n3658>

against

#ifndef BOOST_NOCPP_LIB_INTEGER_SEQUENCE

Obviously if we find SD6 implementations buggy then we'll have to revisit.
|
> Your feeling then is that we should not try to do anything in 
> Boost.config for C++14 features/headers or possiblly C++17 
> features/headers if they are already covered by SD-6 ? What about 
> C++11 features and headers we already have in Boost.config ? You don't 
> see them as being more reliable if we go the SD-6 route and only 
> fallback to our current implementation if SD-6 is not available ?
>
Please be specific, there are already some SD6 checks in the compiler 
configs I believe, and like I said for std lib checks are you suggesting 
that SD6 is better / less buggy than __has_feature for clang?  For GCC 
we need the version check to verify that SD6 exists, and then... 
*nothing happens*, as we don't don't set anything anyway for gcc-5.1 as 
far as I can remember.

John.