Subject: Re: [SG10] __has_include
From: Nelson, Clark (clark.nelson_at_[hidden])
Date: 2013-06-19 20:02:19
> > The advantage is to all users of a compiler that's not based on
> one of those
> > two front ends. (Again, that seems so obvious that I'm
> suspecting some sort
> > of misunderstanding.)
> Those users would benefit more from us recommending that
> implementations provide __has_feature than they would from us
> recommending that implementations provide these two macros in
Let's be really, really clear. Those users will not, strictly speaking,
benefit from our making a recommendation. They will benefit from their
implementer(s) actually following that recommendation. And it is inevitable
that, at least in some cases, there will be a delay before that happens. I'm
concerned about what happens in the interim.
> If we have the former, I don't see value in the latter, so
> I don't see value in us recommending both (just a burden on us to
> keep around those two vestigial macros forever).
The value is in the interim before everyone has an implementation of
> > We're not going to have another teleconference before the
> mailing, so we're
> > going to have to try to develop/recognize consensus on this
> point over the
> > reflector.
> Are there options on the table other than __has_feature and macros
> in <cstddef>?
Not at the moment, at least. All I'm saying is that people should express
up-or-down opinions even if they don't have anything else to contribute to
the discussion, to make sure we have a significant sample size.
> Per above, I'm personally in favor of __has_feature, and I'm
> opposed to macros in <cstddef> if we have __has_feature.
In case it's not already obvious, I'm strongly in favor of the macros, and
weakly in favor of __has_feature in addition.
SG10 list run by firstname.lastname@example.org