Subject: Re: [SG10] __has_[cpp_]attribute
From: Aaron Ballman (aaron_at_[hidden])
Date: 2014-06-02 17:34:38
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-
>> 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
> 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:
# define __has_attribute(x) 0
(Which may be sufficient justification for __has_feature as well.)
SG10 list run by firstname.lastname@example.org