Date: Thu, 20 Jun 2013 23:39:16 +0000
Oops. In this thread, s/__has_feature/__has_include/g
Tom, after you dropped out of the meeting, it was proposed that SG10 recommend that implementations provide the __has_include feature, in addition to actual feature-test macros.
Clark
> -----Original Message-----
> From: Thomas Plum [mailto:tplum_at_[hidden]]
> Sent: Thursday, June 20, 2013 4:30 PM
> To: John Spicer; Nelson, Clark
> Cc: features_at_[hidden]
> Subject: RE: [SG10] __has_include
>
> 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
Tom, after you dropped out of the meeting, it was proposed that SG10 recommend that implementations provide the __has_include feature, in addition to actual feature-test macros.
Clark
> -----Original Message-----
> From: Thomas Plum [mailto:tplum_at_[hidden]]
> Sent: Thursday, June 20, 2013 4:30 PM
> To: John Spicer; Nelson, Clark
> Cc: features_at_[hidden]
> Subject: RE: [SG10] __has_include
>
> 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
Received on 2013-06-21 01:39:36