I am relatively new to C++ and hope that this question is relevant. I
have spent some time at
the local library and some time on dejanews, but have no decided to go
ahead with my question,
since I found no satisfactory answer yet.

It is about composed/aggregated classes. I am developing a scientific
code (Monte Carlo) in
which I find it natural to have classes with several levels of
aggregation.

I am particularly keen on having members in my classes declared as
pointers to classes.
For the large memory requirements I have, this makes sense, since the
actual information
about class sizes presumably comes from some input class/file.

I code this such that the top-class constructor recursively calls the
constructors of its member classes
in the initializer list and this seems very awkward to me.

To take a concrete example directly from the web:

// User.h
class PointerMember;
class RefParam;

class User{
public:
User( const RefParam &inParam );
virtual ~User()

private:
PointerMember *mPointerMember;
};

// User.cpp
#include "User.h"
User::User( const RefParam &inParam )
: mPointerMember( new PointerMember( inParam ) )
{
return;
}

User::~User()
{
delete mPointerMember;
return;
}


I would much rather do the following:

User::User( const RefParam &inParam )
{
mPointerMember = new PointerMember( inParam ); // DON'T DO THIS
return;
}

i.e. I would love to use the constructor body, rather than the
initialization list.

To me this seems natural, as I might like to perform some branching in
the constructor
or get some non-trivial input info, before building member
mPointerMember - operations
that just don't fit the initializer list.

Now, someone in another thread pointed out that another way to proceed
in order to salvage
the initializer list, would be to build a mPointerMember outside
(before calling) the constructor User(....) and pass it as a
reference to User(.....), which then passes it on to a copy
constructor
of the member mPointerMember. However, isn't this rather an awkward
thing to do? Why should
I even think of defining member contents/size outside of their
belonging class.

To make a long story short. May I actually legally use the constructor
body as not suggested
in the above (DON'T DO THIS)?

If not, then where is my reasoning/design wrong?

Thanks for your help,

Chris

"Chris K" <ckoudell@hotmail.com> wrote...
> [...]
> It is about composed/aggregated classes. I am developing a scientific
> code (Monte Carlo) in
> which I find it natural to have classes with several levels of
> aggregation.
>
> I am particularly keen on having members in my classes declared as
> pointers to classes.
> For the large memory requirements I have, this makes sense, since the
> actual information
> about class sizes presumably comes from some input class/file.

This is not how things are in C++. Class sizes are always the same in C++.
Just like object sizes. They are pre-determined by the class definition.
However, objects are often created of a derived type and pointers to a base
type are used to refer to them (what is known as polymorphism), thus making
objects behave differently based on their "true nature".

>
> I code this such that the top-class constructor recursively calls the
> constructors of its member classes
> in the initializer list and this seems very awkward to me.

Again, not a correct statement. The "top-class" constructor does invoke
the other constructor but there is nothing _recursive_ about it. The
two classes are different.

>
> To take a concrete example directly from the web:

How about your own example?

>
> // User.h
> class PointerMember;
> class RefParam;
>
> class User{
> public:
> User( const RefParam &inParam );
> virtual ~User()
>
> private:
> PointerMember *mPointerMember;
> };
>
> // User.cpp
> #include "User.h"
> User::User( const RefParam &inParam )
> : mPointerMember( new PointerMember( inParam ) )
> {
> return;
> }
>
> User::~User()
> {
> delete mPointerMember;
> return;
> }
>
>
> I would much rather do the following:
>
> User::User( const RefParam &inParam )
> {
> mPointerMember = new PointerMember( inParam ); // DON'T DO THIS
> return;
> }
>
> i.e. I would love to use the constructor body, rather than the
> initialization list.

If you _love_ it, do it. There is nothing to stop you.

>
> To me this seems natural, as I might like to perform some branching in
> the constructor
> or get some non-trivial input info, before building member
> mPointerMember - operations
> that just don't fit the initializer list.

Well, that's good enough a reason for me. If you need to do branching,
and don't want to do it in the initialiser list (rather awkward to use
the ternary operator for that sometimes), write it as you have here.

>
> Now, someone in another thread pointed out that another way to proceed
> in order to salvage
> the initializer list, would be to build a mPointerMember outside
> (before calling) the constructor User(....) and pass it as a
> reference to User(.....), which then passes it on to a copy
> constructor
> of the member mPointerMember.

If you are referring to some other post, wouldn't it be better to quote
it instead of re-telling the story with your own words?

> However, isn't this rather an awkward
> thing to do? Why should
> I even think of defining member contents/size outside of their
> belonging class.

Not sure what you mean here, sorry.

>
> To make a long story short. May I actually legally use the constructor
> body as not suggested
> in the above (DON'T DO THIS)?

Of course. Any time you take some code off a web site, just strip all the
comments so you don't see those "DON'T DO THIS" warnings, and the life is
going to get much easier.

> If not, then where is my reasoning/design wrong?

Well, as I pointed out, you have made at least a couple of statements that
suggest your reasoning may not be as straight as you'd like it. Beyond
that... You should probably try to separate several aspects of your design
that are not related and then ask more particular questions on each of
them about which you have a doubt.

Victor