C++ Logo

SG10

Advanced search

Subject: Re: [SG10] __has_include
From: Thomas Plum (tplum_at_[hidden])
Date: 2013-06-20 18:30:20


Would someone please clarify the choices that are currently on the table?

Some of the proposals are supporting __has_feature , and some are supporting __has_include .

Or is there one proposal, and it is supporting both names?

I thought there was a consensus recently that macro names would be pre-defined by any compiler that implements the SG10 recommendations (?)

> -----Original Message-----
> From: features-bounces_at_[hidden] [mailto:features-bounces_at_open-
> std.org] On Behalf Of John Spicer
> Sent: Thursday, June 20, 2013 3:42 AM
> To: Nelson, Clark
> Cc: features_at_[hidden]
> Subject: Re: [SG10] __has_include
>
>
> On Jun 19, 2013, at 9:02 PM, "Nelson, Clark" <clark.nelson_at_[hidden]>
> wrote:
>
> >>> 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
> >> <cstddef>.
> >
> > 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
> > __has_include.
> >
> >>> 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
> >> weakly
> >> 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.
> >
>
> I am in favor of the __has_include solution. We're talking about a
> very narrow part of the whole proposal, which is the issue of dealing
> with the presence of new headers.
>
> The recommendation we discussed on the teleconference was to use
> __has_include. While it is true that only a few implementations have
> that currently, it is reasonable to expect that other implementations
> will add it as they add support for the other macros we suggest.
>
> After all, 2 compilers with __has_include is better than the zero
> compilers that define the other macros we are recommending :-)
>
> I am very troubled by the <cstddef> vs. <stddef.h> issue that was
> brought up and consider that a compelling reason not to introduce
> macros into either or both of those headers.
>
> John.
>
> _______________________________________________
> Features mailing list
> Features_at_[hidden]
> http://www.open-std.org/mailman/listinfo/features


SG10 list run by sg10-owner@lists.isocpp.org