[SG10] Comments from Alisdair

Stephen Kelly steveire at gmail.com
Thu May 29 12:21:16 CEST 2014


Nelson, Clark wrote:

> OK, I have added entries for all of the library issues mentioned by
> Alisdair. No macro for gets, but macros for the other three. For two of
> them, no one gave any feedback, but I went ahead and filled in the obvious
> values. They are all marked by editorial question marks.
> 
> Besides a few tweaks, those are the only changes since I posted it on
> April Fool's Day. I plan to put the result (attached) into the mailing as
> N4030, mainly so we can get more eyes on the __has_cpp_attribute feature.
> 

Hi,

Thanks for working on this.

I have followed this paper for a while, and I notice that while it 
recommends a __has_include() function-like macro, and a 
__has_cpp_attribute() function-like macro, it does not recommend a 
__has_feature() function-like macro, as is used in Clang. As an 
implementation is using it, it might make sense to add why it is not 
recommended. I assume it was discussed long ago, but the reasoning not 
recorded in the paper. 

I can imagine two possible reasons for not recommending it:

1) It is desirable to have non 0/1 values available for each feature (why 
is 
that desirable?), whereas __has_feature() would only expand to 0 or 1.
2) While __has_feature() might be suitable for language features it is 
deemed unsuitable for library features. There is a desire to use a single 
interface for both types of features (Why is that desired?).


If (1) was a valid reason, then it would apply similarly to 
__has_cpp_attribute for consistency, so I assume the only actual reason is 
(2)?

Thanks,

Steve.


More information about the Features mailing list