On Mon, Jun 2, 2014 at 5:10 PM, Nelson, Clark <clark.nelson_at_[hidden]> wrote:
>> My understanding falls short in trying to understand the
>> difference in
>> (possible) recommendation of __has_cpp_attribute and the non-
>> recommendation
>> of __has_feature, where recommending it would seem to be
>> consistent. If it's
>> too much, just let me know and I'll stop trying to understand.
>
> OK, I didn't realize until now that your concern was about the apparent
> inconsistency between not recommending __has_feature and recommending
> __has_[cpp_]attribute.
>
> Would it be fair to restate your questions as, why are we recommending
> something like __has_attribute when we didn't recommend __has_feature?
>
> (Actually, whether that's the exact sense of your question or not, I think
> that's a very, very important question.)

I believe __has_[cpp_]attribute will have the same concerns as
__has_feature regarding preprocessor separation. There's nothing
intrinsic about attribute knowledge within the preprocessor like there
is with __has_include.

In Clang, the preprocessor requests information about attribute
presence from another layer within the compiler. We basically had to
shift attribute knowledge down a layer to accomplish this.

That being said, checking for the presence of this macro has sufficed
within our own code base with:

#ifndef __has_attribute
# define __has_attribute(x) 0
#endif

(Which may be sufficient justification for __has_feature as well.)

~Aaron