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 13:49:10

On 6/13/2015 11:32 AM, Rob Stewart wrote:
> On June 13, 2015 10:01:33 AM EDT, Edward Diener <eldiener_at_[hidden]> wrote:
>> On 6/13/2015 7:13 AM, Rob Stewart wrote:
>>> On June 12, 2015 10:26:49 PM EDT, Edward Diener
>> <eldiener_at_[hidden]> wrote:
>>>> On 6/12/2015 1:05 PM, Peter Dimov wrote:
>>>>> Edward Diener wrote:
>>>>>
>>>>> It seems to me that there's no macro for SD-6 itself though. When
>>>>> __cpp_something is not defined, you don't know whether this is
>>>> because
>>>>> 'something' is not implemented or because SD-6 is not implemented.
>>>>
>>>> What difference could it possibly make ? You test if a macro is
>>>> defined
>>>> and if it is not you try something else. If it is you have your
>>>> answer.
>>>
>>> If the absence of an SD-6 macro implies a feature is not
>> implemented, then the absence of SD-6 support indicates nothing is
>> implemented when that's the mechanism used for discovery of features.
>>
>> But who cares ? Each SD=6 feature test stands on its own. I could care
>> less if a determination is made "somehow" that SD-6 as a whole is not
>> implemented. It doesn't buy me anything.
>
> You're missing the point. If you can't determine whether SD-6 is available, then you can't just check for the presence of an SD-6 macro to decide whether a feature is available. If the macro isn't present, but SD-6 is supported, then the feature isn't available. If SD-6 isn't supported, then you don't know the answer.
>
> Maybe you mean to try an SD-6 macro to see that a feature is implemented and, if that fails, try other methods before giving up and declaring the feature missing.

Yes, that is how I intended SD-6 should be used in Boost.config. I have 
explained that numerous times in my replies on this thread.

> I suppose that a positive answer from an SD-6 macro could be more reliable, but that doesn't account for buggy support that Boost can't use.

Of course not but we already deal with buggy support anyway in config. I 
do not mean to replace config's knowledge now or in the future of buggy 
support for compiler features with blind trust in whatever SD-6 says or 
whatever a particular compiler or standard library says. If we 
empirically know that some feature or standard library implementations 
is not working we mark it accordingly in config. Nothing whatever 
changes in config if we use SD-6 where appropriate in this respect.