What is the difference between these two declarations?

[MasterHacker110]

Well this is not as much as something that I dont know how to implement, but more something that I dont know why I would want to implement it.

When I have a simple class, say this one:

class Cube
{
    public:
        Cube(int x, int y, int z);
        int return_area();

    private:
        int width;
        int height;
        int other;
};

The way that I would normaly expand my functions would be like this:

Cube::Cube(int x, int y, int z)
{
    width = x;
    height = y;
    other = z;
}

int Cube::return_area()
{
    return width * height * other;
}

But recently, in one of my many C++ learning books, the sample code in the book was more like this:

class Cube
{
public:
    Cube(int x, int y, int z): width(x), height(y), other(z) {}

    // all the other code 
};

They both have the same effect of asigning a value to the Cube's varaibles but does this second way have something extra? Is there a reason I should rather use the first way than the second (vice versa)?

[Moschops]

The second constructor there is using an initialisation list. There's no difference in the final state of the object when it's finished.

If any of your member variables were const, or references, the initialisation list would be the only way to set the values. It's also usually faster to use an initialisation list, especially if any member variables are not primitive types.

[rubberman]

A couple of observations:

1. C++ classes have member initializers which should be used OUTSIDE of the main block of the constructor. IE, do this:

   Cube::Cube(int x, int y, int z)
   : width(x), height(y), other(z)
   {
   }

Why? Because you always want your member variables initialized before you can use them. Once you are inside the main block of the constructor, you can use them, initialized or not - BOOM!

So, your second example is correct. If you submitted the first example as an exercise or exam product in one of my classes, you would have been seriously downgraded for that... :-)

[rubberman]

All that said, ALWAYS use the initialization list to set your member variables to some sane default value. Ones that require more complex work to set properly - that CAN be done inside main, but ONLY after you have set a proper default value, even if it is a flag that it wasn't properly initialized for the domain of the class. An example of this might be a file descriptor. Valid values are >= 0. So, if your class has a member that is a file descriptor, initialize it to -1. That way, you can tell easily that it is not something you want to perform I/O on... :-)