Why can't member variable be initialized?

Why can't member variable be initialized (where it is declared)? What's the philosophy behind this rule? Thanks!

If I understand your question correctly, you're asking why you can't do this:

Code:

---

struct A
{
    int i = 0;
};

---

?

If that's the question, then the answer is: because it isn't clear when that assignment should take place written in that way. Any code outside of a function (global initializations etc) must be executed before main(), but here there is not yet any object to initialize. So when would the assignment take place? Presumably, upon construction of an A object, this would specify the initial values of its fields.

That *would* be a perfectly reasonable interpretation....but that just isn't the way they chose to specify it. Instead, you have to do

Code:

---

struct A
{
    int i;
    A(): i(0) {}
};

---

Quote:

---

Originally Posted by acppdummy

Why can't member variable be initialized (where it is declared)? What's the philosophy behind this rule? Thanks!

---

What you are referring to though would be providing default values to member variables at the point of declaration, rather than in each and every constructor.

At the time of creating C (and their structs), there was no such thing as construction. In C++, they probably didn't even think about it. They considered it for C++0x, but finally dropped it.

To be perfectly honest, I think it would be one of those features that provides some nice sugar, but nobody actually really needs, but that would potentially be a snake's pit of extra bugs, obscurely dangerous rules, and bad patterns.

Take for example initializing static const integers at declaration in a class. Some compilers STILL don't support it more than 10 years after standardization, and a lot of developers have to resort to the enum hack. Imagine the chaos this pitiful feature would create. I think that is the philosophy for not importing it.

Any ways, my 2c. I think it's just not the way they did things, and nobody is losing much sleep over it.

Quote:

---

Originally Posted by Lindley

.... Instead, you have to do

Code:

---

struct A
{
    int i;
    A(): i(0) {}
};

---

---

Thank you! I suppose this is equivalent to setting the values in the body of the constructor function? Like

Quote:

---

A(){i=0;}

---

?

Quote:

---

Originally Posted by monarch_dodra

What you are referring to though would be providing default values to member variables at the point of declaration, rather than in each and every constructor.

At the time of creating C (and their structs), there was no such thing as construction. In C++, they probably didn't even think about it. They considered it for C++0x, but finally dropped it.

To be perfectly honest, I think it would be one of those features that provides some nice sugar, but nobody actually really needs, but that would potentially be a snake's pit of extra bugs, obscurely dangerous rules, and bad patterns.

Take for example initializing static const integers at declaration in a class. Some compilers STILL don't support it more than 10 years after standardization, and a lot of developers have to resort to the enum hack. Imagine the chaos this pitiful feature would create. I think that is the philosophy for not importing it.

Any ways, my 2c. I think it's just not the way they did things, and nobody is losing much sleep over it.

---

Thanks!

Quote:

---

Originally Posted by acppdummy

I suppose this is equivalent to setting the values in the body of the constructor function?

---

Not quite: this is initialisation, but assigning in the body of the constructor is assignment. This is an important difference when the member variable is const or of a reference type, and also if the member variable is of a class type whose default constructor does something significant (or which does not have a default constructor). In Lindley's example, it is merely of a built-in type, so there is pretty much no net difference.

Quote:

---

Originally Posted by laserlight

Not quite: this is initialisation, but assigning in the body of the constructor is assignment. This is an important difference when the member variable is const or of a reference type, and also if the member variable is of a class type whose default constructor does something significant (or which does not have a default constructor). In Lindley's example, it is merely of a built-in type, so there is pretty much no net difference.

---

Thank you! There is sill a lot for me to learn. :) So bottom line if the member variable is just simple int or double type then either way is fine, right?

Quote:

---

Originally Posted by acppdummy

So bottom line if the member variable is just simple int or double type then either way is fine, right?

---

Yes, but you might as well use the initialiser list anyway. After all, if you intend to initialise, then initialise, not assign.

Quote:

---

Originally Posted by acppdummy

Thank you! There is sill a lot for me to learn. :) So bottom line if the member variable is just simple int or double type then either way is fine, right?

---

Coding standards often say to put every member in the initializer list (not sure that is the correct term), even if just to default initialize it:

Code:

---

class myClass
{
public:
    myClass() : myString(), //default construction
              myInt(5)  //initialize to 5
    {}

private:
    std::string myString;
    int myInt;
}

---

Something you should take into account is that members are ALWAYS constructed in the same order they are declared in the class body. As such ALWAYS put them in the SAME order in your constructor. While it is legal, to put them in a different order, it is very immoral to do so.

No.

The only members that can be initialised inside the struct/class definition are static const integral members.

What you don't seem to be getting is a struct/class definition is not an object but a map for making objects, a blueprint if you like.

Objects may all be made from the same blueprint but their members may vary widely depending on the arguments passed to the constructor called to make the object. This is why its the constructors job to initialise the variables and why you cant do it as you would seem to like.

Thanks to all again! :)

Quote:

---

Originally Posted by monarch_dodra

At the time of creating C (and their structs), there was no such thing as construction. In C++, they probably didn't even think about it. They considered it for C++0x, but finally dropped it.

---

What was dropped in C++0x? Any references?
The following code is perfectly valid in C++0x (draft version ISO/IEC JTC1 SC22 WG21 N3092)

Code:

---

struct A
{
    int i = 0;
};

---

Quote:

---

Originally Posted by monarch_dodra

As such ALWAYS put them in the SAME order in your constructor. While it is legal, to put them in a different order, it is very immoral to do so.

---

It's also exceedingly difficult to catch a problem if one initialization requires another one already be initialized.

Code:

---

struct autoCString{
  autoCString(char * temp) : myptr(temp), len(strlen(myptr)){}
  ~autoCString(void){free(myptr);}
  int len;
  char * myptr;
};

---

No compiler errors, or even warnings (on most compilers) but will crash every time.

What was the reasoning for this anyway?

Quote:

---

Originally Posted by Marc G

What was dropped in C++0x? Any references?
The following code is perfectly valid in C++0x (draft version ISO/IEC JTC1 SC22 WG21 N3092)

Code:

---

struct A
{
    int i = 0;
};

---

---

Last time I investigated was on september 22nd, one day after the release of draft n3126, when this change appeared on wikipedia's C++0x article.

I tried to find the change in n3126, but couldn't find anything (I mainly searched 9 Classes, 12.6 Initialization and 12.7 Construction). I realize there is no reference associated with the remove, but at the same time, the removed content didn't have references either. I just left it at that.

If anybody could find the correct reference that proves this feature is still (or isn't) in the standard as of draft n3126, I would be thrilled.

If nothing comes up, I'll try to contact User:Kwamikagami to ask him about it.

Quote:

---

Originally Posted by monarch_dodra

If anybody could find the correct reference that proves this feature is still (or isn't) in the standard as of draft n3126, I would be thrilled.

---

That was easy :p
Refer to the example in n3126 clause 12.6.2 paragraph 8.