> When using a member initializer list, the definition of the variables happens
> in the order of their declaration regardless of their order in the list.
> When I define the values of the variables in the constructor, the definition happens,
> as expected, in the order that I define them regardless of their declaration order.
> Did I get that right?
Yes.
When using a member initializer list, the
definition initialization of the variables happens in the order of their declaration regardless of their order in the list.
When I
define assign to the
values of the variables in the constructor, the
definition assignment happens, as expected, in the order that I
define assign to them regardless of their declaration order.
1 2 3 4 5
|
struct A
{
const int n ; // A::n must be initialized, it can't be assigned to
A( int v ) : n(v) {}
};
|
> It's also interesting that it only generated a warning and the result was 0
> rather than an error from trying to do math with an undefined variable.
A construct that may engender
undefined behaviour need not be diagnosed.
Note: It is not possible for a compiler to determine that a particular construct will definitely cause undefined behaviour. With:
1 2 3 4 5
|
struct struct MemberInitializer {
MemberInitializer(int nbr): d2(nbr*2), d1(d2*3) {}
int d1;
int d2;
};
|
It is possible that the type
MemberInitializer is used only in name. Or that every object of type
MemberInitializer that is instantiated has a static storage duration (when members d1 and d2 would be default initialized). It is also possible that the contents of the memory occupied by an uninitialized int happens to have a valid object representation of an int.