Daniel Kr   gler wrote:
[...]
>
> This proposal definitely contradicts the life-time model of

Don't think so. Is there a difference if the variable is initialized
automatically (by calling the default constructor) or by calling a
constructor with arguments ?

Meaning:

class A { MyMember aha;    };
class A { MyMember aha(1); };

class A
{
    A(int x) : aha(x) {}
    MyMember aha;
};


Side effects would be the same as if the arguments are passed in the
constructor.


> C++. 12.6.2 describes the order of initialization (and
> destruction) of bases and members. One very important
> paragraph is 5, here I quote only the last two bullets:
>
> "[..]
> - Then, nonstatic data members shall be initialized in the
> order they were declared in the class definition (again
> regardless of the order of the mem-initializers).
> - Finally, the body of the constructor is executed."
>
> Implementing your idea would cause severe problems,

It would solve all the problems delegating constructors will solve in
C++0x. And if there are problems, couldn't they be solved by changing /
adding other rules ?

> because member initialization can depend on each
> other in the above described ordering. Your proposal
> changes this ordering

I can't see where it would change the ordering. Normally the default
constructor is called, with this proposal a specialized one will be
called. I don't see a difference in the initialization order. The only
difference are additional arguments to a members constructor.

> and we have one more
> (inconsistent) rule to remember.

It could be discussed, that if a member is initialized already in the
class body, it can't be additionally initialized in the class's
constructor again. But nevertheless it wouldn't be IMHO another
inconsistent rule, but it would be simply more straightforward RAII.


> This point has also impact on the order of destruction
> of fully constructed subobjects of partially constructed
> or destructed objects under exceptional situations, see
> 15.2/2.

Same applies to all member variables of a class, so the behavior IMHO
wouldn't change (?).

> Greetings from Bremen,
> Daniel Kr   gler

Greetings
Andre

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

===================================== MODERATOR'S COMMENT:
 Apologies for the delay in moderation; this appears to be caused
by my ISP (Cox) dropping and/or blocking e-mail.


===================================== END OF MODERATOR'S COMMENT
A common bug I often see is uninitialized member variables.  I believe
the main reason for this is being unable to initialize class members
where they are declared.  Because class members are initialized
separately from their definition, it can often be difficult to spot
which variables are being initialized and which ones are not.  I've
read through the specs and can't see a reason why it couldn't be
added.  I'm soliciting comments and hoping someone with the power to
make proposals might decide to champion this idea.

Initializers in the class declaration should come after initializers
in the constructor, but before the constructor definition.
Effectively, a compiler could append initializers in the class
definition to those in the constructor.  All the rules about
initializers on a constructor would apply here as well.  If a variable
is initialized in both places, the one in the constructor should take
precedence.

The following pieces of code would compile to exactly the same result:

class A : public B {
public:
        A ( ) : B( 11 ), i( 42 ), p( 0 ) { }
        A ( int q ) : B( q ), i( 42 ), p( 0 ) { }

        int i;
        char *p;
};

class A : public B {
public:
        A ( ) : B( 11 ) { }
        A ( int q ) : B( q ) { }

        int i = 42;
        char *p = 0;
};

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

===================================== MODERATOR'S COMMENT:
 Apologies for any delays in moderation; this appears to be
caused by my ISP (Cox) dropping and/or blocking e-mail.


===================================== END OF MODERATOR'S COMMENT
On May 8, 5:11 am, bina...@gmail.com wrote:
> Initializers in the class declaration should come after initializers
> in the constructor, but before the constructor definition.
> Effectively, a compiler could append initializers in the class
> definition to those in the constructor.  All the rules about
> initializers on a constructor would apply here as well.  If a variable
> is initialized in both places, the one in the constructor should take
> precedence.

This proposal definitely contradicts the life-time model of
C++. 12.6.2 describes the order of initialization (and
destruction) of bases and members. One very important
paragraph is 5, here I quote only the last two bullets:

"[..]
- Then, nonstatic data members shall be initialized in the
order they were declared in the class definition (again
regardless of the order of the mem-initializers).
- Finally, the body of the constructor is executed."

Implementing your idea would cause severe problems,
because member initialization can depend on each
other in the above described ordering. Your proposal
changes this ordering and we have one more
(inconsistent) rule to remember.

This point has also impact on the order of destruction
of fully constructed subobjects of partially constructed
or destructed objects under exceptional situations, see
15.2/2.

Greetings from Bremen,

Daniel Kr   gler



---
[ 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.comeaucomputing.com/csc/faq.html                      ]