C++ Logo


Advanced search

Re: [SG10] Comments from Alisdair

From: Stephen Kelly <steveire_at_[hidden]>
Date: Thu, 29 May 2014 12:21:16 +0200
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.


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



Received on 2014-05-29 12:30:36