Why is this being voted down? His gripe about the initialiser list order not being the actual initialisation order is perfectly valid. It's intuitive to assume that the variables are going to be initialised in the order that the initialisation code is written - which is exactly the case whenever you initialise something using the equals sign.

Also mentioned in this topic, ordering your members for alignment or caching reasons can potentially break your code if one member was initialised using the value of another.[/quote]

Which would seem like a very good reason not to do that, instead of saying "I'll simply not do proper initialization, so I can make something work, that shouldn't be done in the first place." How many times do you have a situation, where it's not just as easy to initialize both members by the same parameter/default value? And if one value is calculated from the other, how likely is it that one of those isn't redundant and it is vital for your performance to precalculate them both?

And if I need bananas, I'm going to eat good old fashioned apples!

assignment != initialization

By the time your assignment is actually reached, your variables will have already been default-initialized (though it'd probably be optimized out* if the variable isn't accessed before your assignment).

[quote name='taz0010' timestamp='1349502023' post='4987326']
Personally if I have primitive variables that I need to initialise in a specific order, I'm not going to rely on the class definition order to do it, and that means good old fashioned assignment with the = operator.

Why wouldn't you rely on the standardized initialization order?[/quote]I've got a lot of classes that look like:
class Foo
{
Bar bar;
Baz baz;
public: Foo() : bar(42), baz(bar) {}
};, which works fine -- bar is initialized before being passed into baz's constructor. As mentioned earlier, if the initializer list and the variable declaration orders are mismatched, then your compiler should warn you (in this case, a mismatch could cause baz to be passed an uninitialized variable). So far so good.

However, on every shipping game I've worked on, there comes a phase of panic during the final crunch period where the worst-case memory usage of the game is too high, and the QA department is able to produce out-of-memory errors (on consoles). One of the emergency measures that often happens at this point is some poor sod gets given the task of eliminated any unnecessary padding from everyone's data structures, which usually involves going through every class/struct and sorting all member declarations by their sizes (e.g. pushing all chars to the bottom of the class/struct).
Due to the C++ decision to enforce initialization in order of declaration this now causes a conflict -- the initialization list is written in the order that makes logical sense (e.g. so that bar is constructed before being passed to baz) and the declarations are ordered in a way to minimize padding, but C++ wants them both to be the same.
If said poor sod is to complete their assignment, they are now forced to depart from accepted C++ style and start writing horrible looking constructors to trick C++ into satisfying these two conflicting requirements.

I don't know the background behind why the C++ standardization people decided to enforce initialization in declaration order, instead of initialization in initialization order, but IMHO it was a mistake to make that decisiion. Initialization order is bound by logical constraints, but declaration order should only be a concern for memory layout, and should be decoupled from the concern of initialization.
N.B. more modern languages have gotten this right -- e.g. C# declaration order isn't even followed unless you manually specify that you require a certain layout, by default the compiler can rearrange your declarations to the most efficient layout, and allow you to initialize your members in their logical order.

IIRC, it's so that member variables would satisfy the last constructed, first destroyed order that is the general case for variables whose lifetime are managed by the compiler

In theory, the padding/member variable order issue was addressed by allowing the compiler to reorder position of member variables with different access specifiers, but in practice compilers don't actually take advantage of that.[/quote]Wait, the spec says the compiler is allowed to do that? Even after a decade of using this language I'm still learning new quirks...