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.

I emboldened the key part in the above quote -- primitive types aren't default initialized, so when it comes to assigning their default values, then the choice of using the initializer list, or assignment in the constructor body is purely a choice of style. They both generate the same results (unless of course, another item in the initializer list is initialized using the value of a primitive member), so saying one is more correct than the other is nothing more than a style war.

Which is sortof the point I was poorly trying to make. Avoiding the initialization lists because it's 'not reliable' doesn't make sense to me, and being a choice of style, to call one less reliable when they are both standardized is misinformation. What you're saying though, is one is more resistant to side-effects of later code changes, and not that it's non-standard.

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.

I misunderstood taz's point - I thought he was implying that the class definition order is non-standardized, or unreliable. But you are saying that the humans during a crunch are unreliable, and easily mess up important initialization orders by mistake. That makes sense!

Offtopicly: Re-ordering the member variables by size seems rather silly to me (about as silly as re-ordering them based on alphabetizing their variable name), I've never worked in such an environment so there is probably have a good reason for it. Personally, in the few (having not worked on a compact platform) situations I needed to micro-manage the size of variables, I left comments mentioning each of their sizes. How does re-ordering by size help?

(I realize primitive types aren't initialized, and was mixing up initialization with construction - whoops!)

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.

I emboldened the key part in the above quote -- primitive types aren't default initialized, so when it comes to assigning their default values, then the choice of using the initializer list, or assignment in the constructor body is purely a choice of style. They both generate the same results (unless of course, another item in the initializer list is initialized using the value of a primitive member), so saying one is more correct than the other is nothing more than a style war.

Which is sortof the point I was poorly trying to make. Avoiding the initialization lists because it's 'not reliable' doesn't make sense to me, and being a choice of style, to call one less reliable when they are both standardized is misinformation. What you're saying though, is one is more resistant to side-effects of later code changes. (I realize primitive types aren't initialized, and was mixing up initialization with construction - whoops!)

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.

I misunderstood taz's point - I thought he was implying that the class definition order is non-standardized, or unreliable. But you are saying that the humans during a crunch are unreliable, and easily mess up important initialization orders by mistake. That makes sense!

Offtopicly: Re-ordering the member variables by size seems rather silly to me (about as silly as re-ordering them based on alphabetizing their variable name), I've never worked in such an environment so there is probably have a good reason for it. Personally, in the few (having not worked on a compact platform) situations I needed to micro-manage the size of variables, I left comments mentioning each of their sizes. How does re-ordering by size help?

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.

I emboldened the key part in the above quote -- primitive types aren't default initialized, so when it comes to assigning their default values, then the choice of using the initializer list, or assignment in the constructor body is purely a choice of style. They both generate the same results (unless of course, another item in the initializer list is initialized using the value of a primitive member), so saying one is more correct than the other is nothing more than a style war.

Which is sortof the point I was poorly trying to make. Avoiding the initialization lists because it's 'not reliable' doesn't make sense to me, and being a choice of style, to call one less reliable when they are both standardized is misinformation. (I realize primitive types aren't initialized, and was mixing up initialization with construction - whoops!)

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.

I misunderstood taz's point - I thought he was implying that the class definition order is non-standardized, or unreliable. But you are saying that the humans during a crunch are unreliable, and easily mess up important initialization orders by mistake. That makes sense!

Offtopicly: Re-ordering the member variables by size seems rather silly to me (about as silly as re-ordering them based on alphabetizing their variable name), I've never worked in such an environment so there is probably have a good reason for it. Personally, in the few (having not worked on a compact platform) situations I needed to micro-manage the size of variables, I left comments mentioning each of their sizes. How does re-ordering by size help?

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.

I emboldened the key part in the above quote -- primitive types aren't default initialized, so when it comes to assigning their default values, then the choice of using the initializer list, or assignment in the constructor body is purely a choice of style. They both generate the same results (unless of course, another item in the initializer list is initialized using the value of a primitive member), so saying one is more correct than the other is nothing more than a style war.

Which is sortof the point I was poorly trying to make. Avoiding the initialization lists because it's 'not reliable' doesn't make sense to me, and being a choice of style, to call one less reliable when they are both standardized is misinformation.
(I realize they aren't initialized, and was mixing up initialization with construction - whoops!)

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.

I misunderstood taz's point - I thought he was implying that the class definition order is non-standardized, or unreliable. But you are saying that the humans during a crunch are unreliable, and easily mess up important initialization orders by mistake. That makes sense!

Offtopicly: Re-ordering the member variables by size seems rather silly to me (about as silly as re-ordering them based on alphabetizing their variable name), I've never worked in such an environment so there is probably have a good reason for it. Personally, in the few (having not worked on a compact platform) situations I needed to micro-manage the size of variables, I left comments mentioning each of their sizes. How does re-ordering by size help?