[SG10] How closely should our recommendation match clang?

John Spicer jhs at edg.com
Sun Jan 27 19:00:22 CET 2013


On Jan 27, 2013, at 1:05 AM, Nelson, Clark wrote:

>> If two compilers have rvalue references and move constructors, but only
>> one defines the macro, the body of inline function f will be different
>> between implementations.   This is a trivial example -- you can come up
>> with similar cases for just about any language feature.
> 
> But once we come up with a recommendation for a macro to define when a feature is implemented, wouldn't an implementation that has the feature but doesn't define the macro be considered flawed/buggy? I won't go so far as to say "non-conforming", but certainly not of high quality.
> 
> I'm not sure I see the value of taking such perversity into account.
> 

We're loosing how we got to this place in the conversation.     You previously said:

> To me, the most obvious question is whether testing for the presence of a feature should use a function-like syntax, or just an identifier. From a programming perspective, there's no practical difference between these two alternatives:
> 
> __has_feature(cxx_alignas)
> __has_feature_cxx_alignas
> 
> On the other hand, if the function-like syntax is used to test for a feature, somehow there has to be a definition of the function-like macro, or simply testing for the feature is likely to be an error. That would either limit the usefulness of feature-testing, or require users to add boilerplate to conditionally define the function-like macro.

I'm saying that the error is in some ways a "feature" because it prevents you from silently getting the wrong behavior.

Either mechanism requires that a conforming compiler define the needed macro(s).    The function-like syntax lets you know when you are using a that is not supported by your compiler (which can then be worked around, if needed by something like a command-line macro definition).

John.



More information about the Features mailing list