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

Initializing: class within structure

P: n/a
I expect this has been covered somewhere, but I can't find it. Given:

class A { public:
A() {...does stuff...}
};

struct S {
A a;
};

If I create an instance of S, is A's initializer guaranteed to run? Put
differently, is the compiler committed to search down through many
levels to find things with constructors? (I know it will, of course, if
S is a class.)

I've run across verbiage that claims that struct is the same as class
with an initial public: specification, but I thought I recalled that
structs and classes differed more than that. If they don't, if the
intent is to write a POD with public data, just a few simple
constructors and no use of virtual, does it simply make more sense to
use struct, to make that intention clearer?

Thanks.

Jul 11 '06 #1
Share this Question
Share on Google+
5 Replies


P: n/a
ScottM wrote:
I expect this has been covered somewhere, but I can't find it. Given:

class A { public:
A() {...does stuff...}
};

struct S {
A a;
};

If I create an instance of S, is A's initializer guaranteed to run?
Yes. And it is actually called "constructor", not "initializer".
Put differently, is the compiler committed to search down through many
levels to find things with constructors? (I know it will, of course,
if S is a class.)
Yes. There is no difference between 'class' and 'struct' WRT this.
I've run across verbiage that claims that struct is the same as class
with an initial public: specification, but I thought I recalled that
structs and classes differed more than that. If they don't,
They don't.
if the
intent is to write a POD with public data, just a few simple
constructors and no use of virtual, does it simply make more sense to
use struct, to make that intention clearer?
Sure. Of course it depends on who's interpreting your intentions.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Jul 11 '06 #2

P: n/a

"ScottM" <sc***@mayo.nameskrev i meddelandet
news:11*********************@35g2000cwc.googlegrou ps.com...
>I expect this has been covered somewhere, but I can't find it. Given:

class A { public:
A() {...does stuff...}
};

struct S {
A a;
};

If I create an instance of S, is A's initializer guaranteed to run?
Put
differently, is the compiler committed to search down through many
levels to find things with constructors? (I know it will, of course,
if
S is a class.)
Yes, there is no difference. The compiler initializes each member,
which means initializing the member's members, and so on.
>
I've run across verbiage that claims that struct is the same as
class
with an initial public: specification, but I thought I recalled that
structs and classes differed more than that. If they don't, if the
intent is to write a POD with public data, just a few simple
constructors and no use of virtual, does it simply make more sense
to
use struct, to make that intention clearer?
Using a struct as a collection of some related data, is a good idea.
Adding constructors is not, if you want to keep it a POD. PODs are C
style data, which doesn't have constructors.
Bo Persson
Jul 11 '06 #3

P: n/a
ScottM wrote:
I expect this has been covered somewhere, but I can't find it. Given:

class A { public:
A() {...does stuff...}
};

struct S {
A a;
};

If I create an instance of S, is A's initializer guaranteed to run? Put
differently, is the compiler committed to search down through many
levels to find things with constructors? (I know it will, of course, if
S is a class.)
If you don't write a constructor for S, then creating an instance of S
will call A's default constructor. If A doesn't have a default
constructor, then I think you'll get a compiler error. In that case
you will have to write a constructor for S that calls A's constructor.
So, the answer to your question is yes. For structs and classes, the
compiler will construct all "sub-objects" that it can figure out how to
create.
I've run across verbiage that claims that struct is the same as class
with an initial public: specification, but I thought I recalled that
structs and classes differed more than that. If they don't, if the
intent is to write a POD with public data, just a few simple
constructors and no use of virtual, does it simply make more sense to
use struct, to make that intention clearer?
I found a good answer to this in the FAQ:
http://www.parashift.com/c++-faq-lit...s.html#faq-7.8

While you're at it, I recommend reading the whole thing. Lots of good
stuff in there.

Kristo

Jul 11 '06 #4

P: n/a
In message <11*********************@35g2000cwc.googlegroups.c om>, ScottM
<sc***@mayo.namewrites
>I expect this has been covered somewhere, but I can't find it. Given:

class A { public:
A() {...does stuff...}
};

struct S {
A a;
};

If I create an instance of S, is A's initializer guaranteed to run? Put
differently, is the compiler committed to search down through many
levels to find things with constructors? (I know it will, of course, if
S is a class.)
Yes.
>
I've run across verbiage that claims that struct is the same as class
with an initial public: specification,
And default public inheritance.
>but I thought I recalled that
structs and classes differed more than that.
You're possibly thinking of another, slightly related, language with C
in its name.
>If they don't, if the
intent is to write a POD with public data, just a few simple
constructors
If it has constructors it isn't a POD!
>and no use of virtual, does it simply make more sense to
use struct, to make that intention clearer?
Yes. It's a common convention in some circles -- but if you're going to
use it consistently as a documentation tool you need to spell out
exactly what your chosen rules will be.

--
Richard Herring
Jul 11 '06 #5

P: n/a
Got it. Thanks for all replies.

Jul 11 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.