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

Subject: Re: [boost] [config] Using SD-6 macros
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-06-13 09:54:49

On 6/13/2015 4:12 AM, John Maddock wrote:
>
>> 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.

Unless individual compilers and/or standard libraries continue to 
provide "a reliable method" for future releases outside of SD-6 it sure 
seems easier to me to rely on an SD-6 implementation as the first check.

>
> 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

I think it is the fault of users to complain about this. Clearly SD-6 
did not think that including a header to find out if a particular 
feature was available or not is not a great inconvenience.

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

Agreed in principal but I don't think it can be avoided easily in reality.

>
> 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.
> |

Agreed.

>> 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.
> |

I would have thought the correct SD-6 code for this is:

#ifdef __has_include
#if __has_include(<utility>)
#include <utility>
#if __cpp_lib_integer_sequence
#endif
#endif
#endif

>> 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?

I mentioned libc++, Even the checks in libstdc++ are heavily reliant on 
interpreting gcc "versions" from other compilers which use libstdc++, 
like clang. Suppose other compilers start using libstdc++ ? Looking at 
Dinkumware we are currently relying on an internal version number for 
C11 features.

I am not really criticizing as I know how much work you and others have 
done to make config work as well as it does.

>  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.

You don't ever have to do a version check for SD-6 if you just try out 
an SD-6 macro. If it is not defined you just move on to what we are 
doing now in Boost.config, for any given situation.

I totally agree that we should look at each config feature individually 
to see if there is an SD-6 equivalent we can possible use. I also agree 
that as always we shouldn't just be blindly adding features to config 
just because they exist if nobody is asking for them.

My point of view is that for any config feature which has an SD-6 
equivalence, unless you absolutely believe that there is a fail-safe 
method of testing for that feature for a given compiler and/or standard 
library both now and in the future, we can use SD-6 as the first check 
for the feature that we do before we move on to our current check if the 
SD-6 feature check does not exist. I view this as more robust now and 
for the future.