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

Subject: Re: [boost] [config] Using SD-6 macros
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-06-12 22:54:40

On 6/12/2015 2:49 PM, John Maddock wrote:
>
>
> On 12/06/2015 17:53, Edward Diener wrote:
>> On 6/12/2015 12:06 PM, John Maddock wrote:
>>>
>>>
>>> On 12/06/2015 16:21, Edward Diener wrote:
>>>> I realize I may be late to the discussion, but what is the reason why
>>>> Boost.config does not use the SD-6 macro functionality as the first
>>>> check for all C11 and C14 related configuration options ?
>>>>
>>> We haven't needed to, and until recently we haven't had implementations
>>> to check against.  So "history" basically.
>>
>> Some of it, although very clever, seems like educated "guesswork".
>> Isn't it better if the compiler tells us what is omplemented ?
>>
> Sure, but like I said, this has only been very recently supported.

I understand that.

>>>
>>> Plus for compiler features, Clang has __has_feature.
>>
>> OK, that's reliable, as long as the __has_feature we want to check is
>> actually implemented for a given clang release. Of course that's no
>> different than SD-6 except that has_feature is just clang and SD-6 is
>> meant for everybody.
>>
>>>
>>> For std lib features, we're sort of screwed though - you can't check the
>>> SD6 macros without including the std lib header first - and given that
>>> we've already gone to great lengths to make it as lightweight as
>>> possible, including the whole std lib just to check the SD6 macros is
>>> not going to happen.

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 ?

>>
>> About what std lib features are you speaking ? Most of the things I
>> see at
>> https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations
>> are predefined. Are you saying that because the compiler
>> implementations of SD-6 most likely have to include standard library
>> headers in order to implement SD-6 correctly that we should avoid
>> using SD-6 ?
>>
> No, I'm saying we can't check the __cpp_lib* macros without:
>
> a) using __has_include to check the header exists, then
> b) actually including the header.
>>>  Plus as things stand, I don't see what we gain by
>>> duplicating macros which can be checked directly anyway?

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 ?

>>
>> I do not believe the direct checks are as reliable as SD-6.
>>
> What I mean is:
>
> If we don't have a macro for something, but SD6 does, then the user can
> just check SD6 without using Boost.Config at all.

See my previous argument just above.

>
>> If I look at libcpp.hpp we are just checking __cplusplus for a bunch
>> of c11 features and libraries. That seems pretty hit and miss to me.
>> When I asked about a way to check libc++ features for any given libc++
>> release in the clang mailing list the answer was to use SD-6 as a
>> first line of checking.
> Looks like we could do better for some of those: where the compiler is
> clang anyway.  Note the comment though that some of the headers exist,
> but are broken.  Given that there are no useful libc++ (or clang)
> version numbers available, I don't know what we do about that :(

I brought up the "no useful libc++ version numbers" with the libc++ 
developers and Richard Smith was vociferous in saying to use SD-6 as 
they are not going to be backporting anything in libc++ in the face of SD-6.

>> In libstdcpp3.hpp we are doing a much cleverer way of checking, but
>> again when I asked about it on the gcc developers mailing list I was
>> told to use SD-6 if it was available first.
>>
> For GCC5 and later yes, but again, there's very little overlap between
> our config macros and SD6 lib macros at present - GCC5 basically doesn't
> define anything much in libstdcpp.hpp?

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 ?

I am concerned because some of our current implementation seems both 
awfully fragile and an awful amount of continuing work as new compiler 
releases come out, whereas SD-6 offers a solution to much of that 
"drudgery" <g>. And you don't seem to want to take that solution.

>
> John.
>> I understand all the work you and others have put into Boost.config
>> and I am not suggesting that we replace all of Boost.config's checking
>> simply by SD-6, since it is likely to be ages before every compiler
>> supports SD-6, but SD-6 seems like a much more reliable first way of
>> checking a number of features/headers than we are now doing.