Subject: Re: [SG10] __has_[cpp_]attribute
From: Thomas Plum (tplum_at_[hidden])
Date: 2014-06-09 19:36:41
My comments should be taken with several grains of salt, but ...
I recall discussion (Kelly's?) of the real complications where an implementation asserts has_xxxx but the systems people need to be able to over-ride that assertion. That sounds easier to do with a macro naming syntax that can be #undef'd when necessary.
Therefore I'm mildly opposed to has_attribute and has_feature.
> -----Original Message-----
> From: features-bounces_at_[hidden] [mailto:features-bounces_at_open-
> std.org] On Behalf Of Nelson, Clark
> Sent: Monday, June 09, 2014 11:37 AM
> To: features_at_[hidden]
> Subject: Re: [SG10] __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?
> I was actually hoping someone would provide an answer to that question.
> I put __has_cpp_attribute into the document based on my sense of the
> 17 meeting, which I recorded as "some sentiment" in favor. But before
> is discussed in EWG next week, I'd like to have a clearer idea of the
> consensus within SG10. So please reply with your position.
> I myself am opposed -- weakly -- to the __has_attribute syntax, or some
> variation thereof, for all the reasons we didn't go with __has_feature
> 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