It's also important to know the order in which the initializers will be
evaluated. For example, the following definition will cause problems:
class Thingy : public BaseThingy {
public:
Thingy(int endpoint_, int count_) : last(endpoint_), BaseThingy(),
first(last - count_) { }
private:
int first;
int last;
};
The reason this is a problem is that initializers in the constructor
are not executed in the order they are listed, but rather the base
class is always initialized first, followed by the other member
variables in the order those variables are declared in the class
definition. (Then the body of the constructor will be executed after
all the members are initialized.) Thus the three initializers in the
constructor for Thingy will be executed in this order:
BaseThingy() // The base class constructor
first(last - count_)
last(endpoint_)
The problem occurs when initializing the member first, as the
expression calculating the value for first contains a reference to
last-but last has not been initialized yet!
The recommended practice is to always list the initializers in the
order they will be executed.
....
Afterwards it was mentioned also this:
However, I disagree that having a long list of initialized attributes
is necessarily bad. For example, const and reference members must have
initializers. Also, for many C++ experts (see for example Scott Meyers'
Effective C++, Item #12), using initializers for member variables is
the preferred practice for cases where an initializer is possible and
the expressions necessary for producing the constructor arguments don't
make the code unsafe or unreadable. The main reason for this is
efficiency.
I found the texts from:
http://www.physicsforums.com/archive...p/t-67914.html
If you would have data_ before size_ in the attribute list like this:
class test {
private:
int* data_; // <---
size_t size_;
public:
test(size_t s)
: size_(s), data_(new int[s]
{ /* ... */ };
};
then size_ would not have been initialized, when data_ is initialized:
: size_(s), data_(new int[size_])
-You would initialize data_ with an uninitialize size_.
size_ would be initialized after data_ is initialized (with an
uninitialized size_).
But your current code might work ok.
I hope that is the way it goes.