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-12 14:49:33

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

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

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