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 14:44:44

On 6/13/2015 1:28 PM, John Maddock wrote:
>
>>> 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
>>
> Only if you're being unreasonably pedantic - I don't think there are any
> compilers supporting SD6 that don't have <utility> - or indeed any of
> the other headers mentioned in SD6 for that matter.
>
> The point is, if you're the end user, you're going to have to include
> <utility> or whatever anyway, so including it before checking the SD6
> macro for whatever "advanced" feature you're interested in loses you
> nothing.  Boost.Config on the other hand would have to #include
> everything regardless of whether it's being used or not.
>

I agree that is a good argument against using those macros. There are 
some solutions, but they all entail inconvenience to the user of config. 
But until an individual case might be considered I will refrain from 
suggesting any possible solutions.

>> 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.
>>
>
> Edward, I'm sorry but this is all hypothetical at present - we will do
> whatever needs to be done to make things work - that will surely include
> some use of SD6 (especially the compiler-predefined macros).

Good.

>
> What I'm trying to get across is that there is little overlap between
> current Boost.Config macros and SD6 - so the opportunities for
> simplification of what we have are extremely thin on the ground.

Understood.

>
> And you're correct that the libstdc++ config is pretty darn tricky - but
> SD6 doesn't help us a bit for say Clang on libstdc++ - we can't use
> simple __has_include to check for the existence of std lib headers
> because many were hopelessly buggy when first introduced. We can't use
> any compiler intrinsic defines (SD6 or otherwise) because they have no
> relation to the std lib.  We can't use libstdc++ version numbers because
> they're simple release dates that have no correspondence to GCC version
> and/or feature sets.  So that leaves us back with trying to infer the
> GCC release as now - and once you have that you have the info you need
> to configure anyway.
>
>> 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.
>
> Unfortunately that's not quite true - sometimes you can't reliably
> include a std lib header even when __has_include reports true as noted
> above.

You chided me for not being specific so now I will chide you. Please 
point out to me one case or more where the SD-6 implementation is buggy 
in this respect. I don't mean that the header is buggy, because that's 
something that config rightly deals with, but that __has_include tells 
you that a header exists where it does not. I don't think that situation 
exists and if it did it would be a serious compiler implementation of an 
SD-6 implementation error.

Just to finish what I hope is more of an agreement than a disagreement 
about anything regarding SD-6, as I understand you in this area and I 
believe you understand me, I am not blindly just advocating SD-6 to tell 
us everything about everything it can and then just have config just 
accept it as the final word.

I got a lot of flac <g> when I queried in the libc++ and libstdc++ 
mailing lists to find out how to decide if shared_mutex was part of any 
given library implementation either now or in the future. The answer I 
received from libc++ was an absolutely unequivocal one that SD-6 is the 
only way you will ever find out with certainty, other than an empirical 
test with a particular compiler's implementation that uses libc++, 
whether a libc++ implementation supports any given standard library 
feature. With libstdc++ I received much the same answer to use SD-6 in 
the future, even though I can plainly see now that gcc 4.9.n includes 
standard_mutex but SD-6 is not implemented until gcc-5.1. With 
Dinkumware I could not find out anything, but evidently Dinkumware is 
VC++ for all Boost's intents and purposes so what is decided is based on 
VC++ releases. Still even here I feel like its pretty difficult since it 
seems all empirical with each VC++ release.

I felt, not entirely naively, that SD-6 where appropriate, would be a 
solution.

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