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 13:28:11

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

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.

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.

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.
>
>
>
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
> .
>