Subject: Re: [SG10] __has_[cpp_]attribute
From: Jens Maurer (Jens.Maurer_at_[hidden])
Date: 2014-06-13 17:33:49
__has_include(x) directly maps to the question
whether "#include x" is going to work.
That does not express any opinion on the semantics
or contents of "x", it's simply a (very) basic
filesystem "exists" test.
I like __has_include(x).
For the actual language features, we have explicit
(distinct) macros, because there is nothing that
would hint at the spelling for "x", and the
spelling of the feature actually needs to be connected
to specific semantics (e.g. in an N-paper).
For attributes, the question boils down whether
__has_attribute(x) gives enough information to
successfully use "x". For simple attributes without
variations or evolution, that's certainly true
("deprecated"). So maybe this is a good starting point.
But what happens if we get v2 of the attribute "x"
(for example, with an additional parameter)?
Is this rare enough that we should go with __has_attribute(x)
and then do __has_attribute(x2), or (for the rare case)
then start to have a distinct macro __attribute_x_v2?
Or will __has_attribute(x) return the year / month pair
that our regular macros do?
I think I'm weakly in favor of __has_attribute(x).
>> -----Original Message-----
>> From: features-bounces_at_[hidden] [mailto:features-bounces_at_open-
>> std.org] On Behalf Of Nelson, Clark
>> Sent: Monday, June 09, 2014 2:37 PM
>> To: features_at_[hidden]
>> Subject: Re: [SG10] __has_[cpp_]attribute
>>>> Would it be fair to restate your questions as, why are we
>>>> something like __has_attribute when we didn't recommend
>> I was actually hoping someone would provide an answer to that
>> I put __has_cpp_attribute into the document based on my sense of
>> the March
>> 17 meeting, which I recorded as "some sentiment" in favor. But
>> before this
>> is discussed in EWG next week, I'd like to have a clearer idea of
>> consensus within SG10. So please reply with your position.
>> I myself am opposed -- weakly -- to the __has_attribute syntax, or
>> variation thereof, for all the reasons we didn't go with
>> __has_feature in
>> the first place, as I explained a couple of weeks ago.
>> Clark Nelson Vice chair, PL22.16 (ANSI C++ standard
>> Intel Corporation Chair, SG10 (C++ SG for feature-testing)
>> clark.nelson_at_[hidden] Chair, CPLEX (C SG for parallel language
>> Features mailing list
SG10 list run by firstname.lastname@example.org