another question on using The colon :

In the following snippet of code, what is the significance of the colon ( : ) after Tree::Tree() and after Tree::Tree(Node const &node)? Is it supposed to mean that Tree::Tree() inherits from left(0), or the two subtrees and the node?

Code:

#include "tree.h"
//default constructor: initializes to 0
Tree::Tree()
:  // what does this colon signify?
  left(0),
  right(0),
  node(0)
{
}

// Node constructor: adda Node object
Tree::Tree(Node const &node)
:  //what does this colon mean?
  left(0),
  right(0),
  node(node.clone())
{
}

That colon means that what follows is an initializer list. In constructor definitions, between the name and the body can sit an initializer list. This code:

Code:

Tree::Tree()
:  // what does this colon signify?
  left(0),
  right(0),
  node(0)
{
}

Sets left, right, and node to 0. It's mostly the same as:

Code:

Tree::Tree()
{  
  left = 0;
  right = 0;
  node = 0;
}

but the first method is preferred. There are differences:

* Initializer lists can offer improved performance.
* Initializer lists are the ONLY place you can correctly call a base constructor.
* Initialization happens in the order the variables are defined, NOT the order of the list itself. E.g. in this code:

Code:

class X{
public:
  X() : y(0), x(7), z(22){}
private:
  int x, y, z;
};

The variables are instantiated beginning with *x*, then y, then z, because that is the order they are declared in the class. The order they are declared in the initializer list is irrelevant (although, for readability, I always make both orders the same).

Cat:

Why is the first method prefered?

It can be more efficient, and in some cases, there is no alternative. Calling base constructors or constructing members without using the default constructor are two examples.

Further, having an empty-bodied constructor can help optimizing compilers.

Here's an efficiency example. Imagine class X has an object of class Point called P.

X::X():p(10,10){}
// This constructs the object p once with 10,10 as params.


X::X(){p = Point(10,10);}
// p is first default constructed, then a new temporary point object is constructed and assigned to p.
// This won't even compile unless Point has a default constructor.

Another example, calling a base constructor:

Derived::Derived() : Base(43, "hello") {}
// It correctly calls the base constructor for the object

Derived::Derived() { Base(43, "hello"); }
// This doesn't do even close to the same thing. The default Base constructor is called.
// The call in the body actually creates and immediately destroys a temporary object of type Base. It has no effect on the Derived object.

Additional to what Cat said.

Cat:
Why is the first method prefered?

This calls the constructor for the object. The second method calls the constructor and the copy assignment operator. This is a perfomence bottleneck if the classes are BIG.

Another necessary place for the initializer list are member constants.

I don't understand. How can initializing member data using initializer lists or in the body make a difference? Isn't it all the same in assembly language anyway? I mean, all that happens is that a memory location is filled with a value.

>How can initializing member data using initializer lists or in the body make a difference?
Try initializing a const data member in the body of the constructor. Then try using an initializer list. See the difference?

Originally posted by bennyandthejets
I don't understand. How can initializing member data using initializer lists or in the body make a difference? Isn't it all the same in assembly language anyway? I mean, all that happens is that a memory location is filled with a value.

Here's one example:

Code:

X::X():p(10,10){} 

X::X(){p = Point(10,10);}

The first calls the constructor of Point once. The second calls it twice and calls the assignment operator once.

Further, even with primitive types, it's NOT always the same. Compilers are allowed to do all kinds of magic behind the scenes, and when you put stuff in the list, they're allowed by the language to do different and more aggressive optimizations.