Date: Tue, 3 Feb 2015 16:36:01 -0800
On Tue, Feb 3, 2015 at 4:01 PM, Nelson, Clark <clark.nelson_at_[hidden]>
wrote:
> > > We did quite a bit of surgery to enumerations in C++11,
> > > e.g. we can now have explicit base types and scoping etc.
> >
> > > I'm wondering why we're highlighting the "forward declaration"
> > > part, as opposed to just "__cpp_extended_enum" or simply
> > > "__cpp_enum", with suitably-changing values?
>
>
> > I'm in two minds about this: by putting all the changes under the same
> > name, we present a problem to implementations who implement only part of
> > the new rules: they can't bump the version of their __cpp_enum macro
> until
> > they implement the whole lot. But I do like avoiding the proliferation of
> > macros tracking tiny changes, so if we don't anticipate any
> implementations
> > in that state, then I'd prefer the more general macro name.
>
> Let me make my position clear.
>
> As editor/chair, I added that to the document because I received a specific
> request, and I'm giving SG10 a chance to discuss it and decide about it.
>
> But for my money, C++11 was already a lost cause when we started our work.
> The partial implementations that already exist (except clang, of course)
> have no feature-testing facilities, and defining them after the fact isn't
> going to turn back the clock. So I am at best apathetic about C++11 macros.
>
> Actually, if I were to stop and think about it, I would probably conclude
> that recommending that implementations add a bunch of macros to their
> already-virtually-complete implementations of C++11 would just pollute the
> preprocessor's symbol table for virtually no benefit, and wouldn't be
> worth our time.
>
> But as editor, I'm happy to do what SG10 tells me should be done. :-/
Your position makes a lot of sense to me, assuming that we can trust that a
vendor doesn't define __cplusplus to 201103L until they're actually
feature-complete, and that we don't expect that any new implementation is
going to come along and implement C++ features in standards-order (03 then
11 then 14). I see the job of SG10 as improving the future, not attempting
to fix the past.
Would the conclusion of that position be that we don't backfill for
features that are already implemented in every shipping compiler we're
collectively aware of?
wrote:
> > > We did quite a bit of surgery to enumerations in C++11,
> > > e.g. we can now have explicit base types and scoping etc.
> >
> > > I'm wondering why we're highlighting the "forward declaration"
> > > part, as opposed to just "__cpp_extended_enum" or simply
> > > "__cpp_enum", with suitably-changing values?
>
>
> > I'm in two minds about this: by putting all the changes under the same
> > name, we present a problem to implementations who implement only part of
> > the new rules: they can't bump the version of their __cpp_enum macro
> until
> > they implement the whole lot. But I do like avoiding the proliferation of
> > macros tracking tiny changes, so if we don't anticipate any
> implementations
> > in that state, then I'd prefer the more general macro name.
>
> Let me make my position clear.
>
> As editor/chair, I added that to the document because I received a specific
> request, and I'm giving SG10 a chance to discuss it and decide about it.
>
> But for my money, C++11 was already a lost cause when we started our work.
> The partial implementations that already exist (except clang, of course)
> have no feature-testing facilities, and defining them after the fact isn't
> going to turn back the clock. So I am at best apathetic about C++11 macros.
>
> Actually, if I were to stop and think about it, I would probably conclude
> that recommending that implementations add a bunch of macros to their
> already-virtually-complete implementations of C++11 would just pollute the
> preprocessor's symbol table for virtually no benefit, and wouldn't be
> worth our time.
>
> But as editor, I'm happy to do what SG10 tells me should be done. :-/
Your position makes a lot of sense to me, assuming that we can trust that a
vendor doesn't define __cplusplus to 201103L until they're actually
feature-complete, and that we don't expect that any new implementation is
going to come along and implement C++ features in standards-order (03 then
11 then 14). I see the job of SG10 as improving the future, not attempting
to fix the past.
Would the conclusion of that position be that we don't backfill for
features that are already implemented in every shipping compiler we're
collectively aware of?
Received on 2015-02-04 01:36:03