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

Initialization of non-integral type in initialization list

P: n/a
class CustomType
{
public:
CustomType(){_i = 0;}
CustomType(int i) : _i(i) {}
private:
int _i;
};

class MyClass
{
public:
MyClass() : _member(4){}
private:
CustomType _member;
};

Will _member be ever created before the initialization list in MyClass?
Am I guarantueed that it will only get created that once?

I have run some tests, but I can't tell if my results are
implementation specific, or undefined behaviour. Is this the right way?

Dec 11 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a

an**************@googlemail.com wrote:
class CustomType
{
public:
CustomType(){_i = 0;}
CustomType(int i) : _i(i) {}
private:
int _i;
};

class MyClass
{
public:
MyClass() : _member(4){}
private:
CustomType _member;
};

Will _member be ever created before the initialization list in MyClass?
Am I guarantueed that it will only get created that once?

I have run some tests, but I can't tell if my results are
implementation specific, or undefined behaviour. Is this the right way?


Sorry for all of the questions today. I've been writing a lot of
programs to fill up grey areas in my knowledge.

A further question: Imagine CustomType is an ABC. There's no way I can
initialize that in the initialization list, is there? I'd actually have
to use a pointer in this case, and assign it a value from making a new
concrete class down the inheritance chain, right?

Dec 11 '05 #2

P: n/a
an**************@googlemail.com wrote:
class CustomType
{
public:
CustomType(){_i = 0;}
Use Constructor initialization list
CustomType() : _i(0) { } ;
CustomType(int i) : _i(i) {}
private:
int _i;
};

class MyClass
{
public:
MyClass() : _member(4){}
private:
CustomType _member;
};
Donot use names starting with an underscore - they are reserved for
implementation.
Will _member be ever created before the initialization list in MyClass?
Am I guarantueed that it will only get created that once?

the initialization list will initialize the member "_member" when
constructor of the class CustomType is called. Space for _member is
reserved when you instantiate the class. This is immediately followed
by the constructor call to initialize the object. So , though the
object creation and initialization take place at two distinct points in
time, as far as the programmer is concerned, they are "atomic".

Also, if a member is of a user-defined type and it is not initialized
in the constructor initialization list, then the compiler calls the
default constructor for that member before executing the code of the
constructor.


A further question: Imagine CustomType is an ABC. There's no way I can
initialize that in the initialization list, is there? I'd actually have
to use a pointer in this case, and assign it a value from making a new
concrete class down the inheritance chain, right?


If CustomType is an absract base class, you cannot have an instance of
CustomType as a member of MyClass. So you are right in pointing out
that you would actually need a pointer there.

HTH.

Dec 11 '05 #3

P: n/a
Neelesh Bodas wrote:
Donot use names starting with an underscore - they are reserved for
implementation.


No they aren't. Only ones begining with underscore followed by an
uppercase letter, or those in the global namespace. His member
variables here are fine as far as the language is concerned.
Dec 11 '05 #4

P: n/a
an**************@googlemail.com wrote:

Will _member be ever created before the initialization list in MyClass?
Am I guarantueed that it will only get created that once?

The initialization list is just a indication of the initializers that
are used when the appropriate initialization occurs. It has no bearing
on the order of initialization, regardless of the order of the
inializers in the list, or by their absence.

Construction always occurs in a definite order:

1. Any virtual base classes are initialized for the most derived object.

then

2. Recursively, the any non-virtual bases are initialized, in the
order they are declared in the class definition(i.e., after the
colon that follows the class name, NOT the member initializer list).

3. All non-static members are initialized in the order they are listed
in the class definition.

4. The body of the constructor is run.

All the initializer list does is say that when that constructor is used,
then those parameters are used to initialize the listed subobject when
the time for that initialization occurs as specified above.
Dec 11 '05 #5

P: n/a

Ron Natalie wrote:
Neelesh Bodas wrote:
Donot use names starting with an underscore - they are reserved for
implementation.


No they aren't. Only ones begining with underscore followed by an
uppercase letter, or those in the global namespace. His member
variables here are fine as far as the language is concerned.


Strangely, almost all of the C++ code I've seen uses an underscore in
private variables. Is this not actually a common thing to do?

Dec 11 '05 #6

P: n/a
an**************@googlemail.com wrote:
Ron Natalie wrote:
Neelesh Bodas wrote:
Donot use names starting with an underscore - they are reserved for
implementation.

No they aren't. Only ones begining with underscore followed by an
uppercase letter, or those in the global namespace. His member
variables here are fine as far as the language is concerned.


Strangely, almost all of the C++ code I've seen uses an underscore in
private variables. Is this not actually a common thing to do?

A lot of people use a trailing underscore. I tend to do neither.
For me a well designed class doesn't require any special decoration
on the member variables. Member variables aren't visible outside
the class, and a class member function rarely touches a variable
outside the class, so what's the point?
Dec 11 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.