By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,603 Members | 1,461 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,603 IT Pros & Developers. It's quick & easy.

Quick question about initializing

P: n/a
Given a simple class like

class test {
private:
size_t size_;
int* data_;
public:
test(size_t s)
: size_(s), data_(new int[s]
{ /* ... */ };
};

I'm curious as to whether there's any differance if I change the
initialization list to:

: size(s), data_(new int[size_])

if we disregard the possible trouble that might cause if I happened to
declare data_ first?

--
Erik Wikström

Nov 15 '06 #1
Share this Question
Share on Google+
2 Replies


P: n/a


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.

Nov 15 '06 #2

P: n/a

<er****@student.chalmers.sewrote in message
news:11********************@b28g2000cwb.googlegrou ps.com...
Given a simple class like

class test {
private:
size_t size_;
int* data_;
public:
test(size_t s)
: size_(s), data_(new int[s]
{ /* ... */ };
};

I'm curious as to whether there's any differance if I change the
initialization list to:

: size(s), data_(new int[size_])

if we disregard the possible trouble that might cause if I happened to
declare data_ first?
Also disregarding the errors? :-) (You left off the closing parentheses in
the first example, and the ending underscore for size_ in the second.)

I guess you're just asking if using s versus size_ makes a difference. In
this case, probably not. (There might be a small performance difference on
some compilers, especially in unoptimized (i.e., debug) code, but I doubt
it. You could check the assembler output from each to see what yours does.)

But as long as size_ is declared before data_, it will get initialized
first, so there should be no problems. (I prefer the first version, though,
just in case the declaration order DOES get changed!)

-Howard


Nov 15 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.