In article <1116894563.921382.121370@g44g2000cwa.googlegroups.com>,
Marcus <yuu@yyhmail.com> writes
>I have read your work on initialisation syntax and I liked it very
>much.
Thanks for the encouragement. However we have realised that the problems
are deeper and more extensive than I had previously understood. In fact
Those working with me are coming to the strong belief that there is no
one who actually understands all the implications of the Standard as
regards the type system and initialisation. Our first task is to get a
clear understanding of where we are and share that understanding with
the rest of those working on the next version of C++. Then we will be
able to make intelligent choices for the future rather than continuing
with patching up a very shaky system.

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hello!

It's known that member initializers (is the term correct?) are executed
in the order of the members in the class, not in the order they're
written in the constructor. It's a problem for beginners and for
maintenance of programs. For example:

class SomeClass
{
  double x, y;
public:
  SomeClass(): y(8.0), x(y) {} // BAD
};

Here, the x initializer is run before y's. GCC warns about this, but
warnings can be turned off and other compilers may not warn. Since
there's no real benefit from writing initializers in a different order
(except to confuse other programmers), I propose changing this warning
to an error. Maybe correct programs will break with this change
(programs where the order of initialization doesn't matter), but the
language will be easier to teach and will make this kind of bug (the
one show in the example above) impossible.

There are other solutions to this problem:
1. Instead of an error, use a "standard warning". I don't know if it's
usual for the standard committee to mandate warnings, but this would be
very useful if backwards compatibility is preferred. My preference is
to issue an error, though.
2. Initilize members in the order they appear in the constructor. To
me, this would be an obvious choice as it matches the beginners
expectations. Programs that have both declarations and initializations
in the same order wouldn't break. But I think there are other issues
involved, otherwise this problem would have been solved years before.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Marcus wrote:
> Hello!
>
> It's known that member initializers (is the term correct?) are executed
> in the order of the members in the class, not in the order they're
> written in the constructor. It's a problem for beginners and for
> maintenance of programs. For example:
>
> class SomeClass
> {
>   double x, y;
> public:
>   SomeClass(): y(8.0), x(y) {} // BAD
> };
>
> Here, the x initializer is run before y's. GCC warns about this, but
> warnings can be turned off and other compilers may not warn. Since
> there's no real benefit from writing initializers in a different order
> (except to confuse other programmers), I propose changing this warning
> to an error. Maybe correct programs will break with this change
> (programs where the order of initialization doesn't matter), but the
> language will be easier to teach and will make this kind of bug (the
> one show in the example above) impossible.
>
> There are other solutions to this problem:
> 1. Instead of an error, use a "standard warning". I don't know if it's
> usual for the standard committee to mandate warnings, but this would be
> very useful if backwards compatibility is preferred. My preference is
> to issue an error, though.

This is one of those cases where I agree it should have just been "done
right" originally, but changing it might annoy alot of programmers now.
It could be depricated I suppose. Personally I would like to see
compilers always by default run at an error level which would display
things like this, so it wouldn't catch out beginning users.

> 2. Initilize members in the order they appear in the constructor. To
> me, this would be an obvious choice as it matches the beginners
> expectations. Programs that have both declarations and initializations
> in the same order wouldn't break. But I think there are other issues
> involved, otherwise this problem would have been solved years before.
>

Consider your example, but replace double with some class Foo. Clearly x
could take a reference to y, and therefore you would have make sure in
destruction you destroyed variables in the opposite order to how they
were constructed. If different constructors could do it in different
orders, then you would have to somehow store in the class an extra piece
of information to tell you the order in which to destroy them, which was
considered unacceptable overhead I believe.

Chris

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Marcus wrote:
> 2. Initilize members in the order they appear in the constructor. To
> me, this would be an obvious choice as it matches the beginners
> expectations. Programs that have both declarations and
initializations
> in the same order wouldn't break. But I think there are other issues
> involved, otherwise this problem would have been solved years before.

This is not really an option as the destructor must destroy objects in
the reverse order they where created. And what should be done if
different constructors exist with different construction ordering.
Enforcing the order is the only way.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <1116792458.779206.287010@g47g2000cwa.googlegroups.com>,
Marcus <yuu@yyhmail.com> writes
>1. Instead of an error, use a "standard warning". I don't know if it's
>usual for the standard committee to mandate warnings, but this would be
>very useful if backwards compatibility is preferred. My preference is
>to issue an error, though.

The Standard has no concept of warning v error. The requirement is for a
diagnostic. Whether an implementation elects to continue compilation
after issuing a diagnostic is almost entirely up to the implementor.

Personally, I might well have advocated that mem init lists must handle
members and bases in the order of declaration but I think that is water
under the bridge and it is far too late to make that change now. The
cost in broken code would be very high and the gain would be very small.
Yes I am all in favour of making C++ (much) easier to teach but I think
we have much more serious issues to address (such as the whole type
system and initialisation syntaxes)

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:
> In article <1116792458.779206.287010@g47g2000cwa.googlegroups.com>,
> Marcus <yuu@yyhmail.com> writes
>
>> 1. Instead of an error, use a "standard warning". I don't know if it's
>> usual for the standard committee to mandate warnings, but this would be
>> very useful if backwards compatibility is preferred. My preference is
>> to issue an error, though.
>
> The Standard has no concept of warning v error. The requirement is for a
> diagnostic. Whether an implementation elects to continue compilation
> after issuing a diagnostic is almost entirely up to the implementor.
>
> Personally, I might well have advocated that mem init lists must handle
> members and bases in the order of declaration but I think that is water
> under the bridge and it is far too late to make that change now. The
> cost in broken code would be very high and the gain would be very small.
> Yes I am all in favour of making C++ (much) easier to teach but I think
> we have much more serious issues to address (such as the whole type
> system and initialisation syntaxes)
>

I agree with you. However if the feature were to be just formally
deprecated but not removed, as suggested by Chris Jefferson, the
compilers would have a very good reason for providing a diagnostic
without breaking any existing code, so I believe it is a possibility
that could be considered.

BTW, just a curiosity: are there parts of appendix D which are going to
be formally removed in the next revision of the standard?

Alberto

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

chris jefferson wrote:

> Marcus wrote:
>
>> Hello!
>>
>> It's known that member initializers (is the term correct?) are executed
>> in the order of the members in the class, not in the order they're
>> written in the constructor. It's a problem for beginners and for
>> maintenance of programs.

    Of course, the right answer is a dependency sort at compile
time, like Modula II.

    One of the better features of Modula II was that initialization
order issues were worked out by the compiler.  If the compiler
couldn't determine a valid initialization order (usually
meaning there was a loop) link time errors appeared.

    C++ static initialization also could use a dependency sort.

    John Nagle

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow escreveu:
> In article <1116792458.779206.287010@g47g2000cwa.googlegroups.com>,
> Marcus <yuu@yyhmail.com> writes
> >1. Instead of an error, use a "standard warning". I don't know if
it's
> >usual for the standard committee to mandate warnings, but this would
be
> >very useful if backwards compatibility is preferred. My preference
is
> >to issue an error, though.
>
> The Standard has no concept of warning v error. The requirement is
for a
> diagnostic. Whether an implementation elects to continue compilation
> after issuing a diagnostic is almost entirely up to the implementor.

I didn't know that. Thanks. I think it's weird, but it's fine :-)

> Personally, I might well have advocated that mem init lists must
handle
> members and bases in the order of declaration but I think that is
water
> under the bridge and it is far too late to make that change now. The
> cost in broken code would be very high and the gain would be very
small.
> Yes I am all in favour of making C++ (much) easier to teach but I
think
> we have much more serious issues to address (such as the whole type
> system and initialisation syntaxes)

I have read your work on initialisation syntax and I liked it very
much.

But i see many people in comp.std.c++ suggesting more and more features
without thinking about the pitfalls that C++ has. Like what Walter
Bright says to promote his language, D:
"""
There's no need for multiple warning levels in D, a "D Puzzle Book", a
lint program, a "Bug Of The Month", or a world's leading expert on
preprocessor token concatenation.
""" (http://www.digitalmars.com/d/sdwest/paper.html)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <Rltke.114429$IN.1951019@twister2.libero.it>, Alberto Barbati
<AlbertoBarbati@libero.it> writes
>BTW, just a curiosity: are there parts of appendix D which are going to
>be formally removed in the next revision of the standard?

No idea, to be honest that is the least of our worries.

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]