469,898 Members | 1,586 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,898 developers. It's quick & easy.

Ctor initialization lists: three details beyond the FAQ-lite

Hi!

A) Why isn't it possible to set a member of the BASE class in
an initialization list of a DERIVED class constructor (except for
'calling' the base constructor from there, of course)? I even
tried prefixing them with BASE:: but to no avail. Still it's
ok when I set them in the construtor body, not the init list.
Does this mean that it's a small advantage of the initialization
inside the constructor over initialization in the init list
(though I know the init lists are 'cleaner' in general).

B) Is it, on the other hand, possible (looks to me like it is)
to use the values of BASE class members to initialize DERIVED
class members in the initialization list?

C) I know the initialization lists do not support the syntax
to initialize structs all at once, but why they don't allow
to initialize struct *members* like in
foo::foo() : bar.x(0), bar.y(0) {};
is beyond me. Why aren't members of structs treated like
'ordinary variables'? I know it's easiest to add a constructor
to the struct and to use it in the init list, but I'm just
curious...

TIA,
- J.
Jul 22 '05 #1
1 3925
On Mon, 19 Apr 2004, Jacek Dziedzic wrote:
Hi!

A) Why isn't it possible to set a member of the BASE class in
an initialization list of a DERIVED class constructor (except for
'calling' the base constructor from there, of course)? I even
First, note that initializing the base by calling its constructor, and
initializing the base by initializing its members, is mutually
exclusive.

Second, the constructor of a derived class cannot, in general,
initialize every member of the base class, since the derived class does
not have access to private members of its base.

Third, the base class constructor establishes the class invariant of the
base class. If the constructor of a derived class could directly
initialize members of its base, it would need to assume this task in
addition to that of establishing its own invariant. But it is not
generally in a position to do so without having access to all members of
the base.

In terms of construction, a base class behaves similar to an aggregated
class, and this seems a good idea since it enhances encapsulation.

tried prefixing them with BASE:: but to no avail. Still it's
ok when I set them in the construtor body, not the init list.
Does this mean that it's a small advantage of the initialization
inside the constructor over initialization in the init list
(though I know the init lists are 'cleaner' in general).
There is no initialization inside the constructor's body.

B) Is it, on the other hand, possible (looks to me like it is)
to use the values of BASE class members to initialize DERIVED
class members in the initialization list?
Yes, since the base class constructor has been called before any member
of the derived class is initialized.

C) I know the initialization lists do not support the syntax
to initialize structs all at once, but why they don't allow
to initialize struct *members* like in
foo::foo() : bar.x(0), bar.y(0) {};
is beyond me.
The initialization list allows you to initialize the class members. The
only way to initialize a member struct (i.e. class) is by calling its
constructor.
Why aren't members of structs treated like
'ordinary variables'? I know it's easiest to add a constructor
to the struct and to use it in the init list, but I'm just
curious...

TIA,
- J.


--
Claudio Jolowicz


Jul 22 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

9 posts views Thread by Dave H | last post: by
41 posts views Thread by Odd-R. | last post: by
7 posts views Thread by Razzie | last post: by
5 posts views Thread by PasalicZaharije | last post: by
4 posts views Thread by Jacek Dziedzic | last post: by
5 posts views Thread by Grahamo | last post: by
10 posts views Thread by utab | last post: by
3 posts views Thread by John Salmon | last post: by
51 posts views Thread by Joerg Schoen | last post: by
reply views Thread by Salome Sato | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.