heap vs. stack

[Brian Buderman]

Consider the creation of a class library, where the desire is to allow
the user of the library to chain objects together during construction in
a single statement. For example, this statement uses the heap:

topLevelObject = new type1(new type2(new type3(), new type4());

While this example only uses 4 types, in actuality there will object
trees with a much higher count. Some of the types accept abstract
interfaces, and typeinfo must be maintained such that the library can
correctly traverse the object tree. After construction of these object
trees, the user will pass them to another library object, and be done
with it.

Is it best to:

a. Use pointers, and delete pointers automatically in each class
destructor (freeing user from deleting them but preventing them from
keeping a reference)

b. Use pointers, and require user to delete pointers manually (thus
killing the ability to chain the construction since a pointer to each
object now needs to be kept)

c. Use references - though I'm not sure how that would work with
abstract types...how would you pass an inline contructed derived class
reference where the abstract class reference is expected?

My inclination is to use choice a, though I know pointers are not type
safe, and I'm not sure how good of an idea it is to automatically delete
all the objects in the tree.

Thoughts?

Thanks in advance.

[noone]

On Sun, 17 Dec 2006 23:18:25 -0500, Brian Buderman wrote:

Consider the creation of a class library, where the desire is to allow the
user of the library to chain objects together during construction in
a single statement. For example, this statement uses the heap:

topLevelObject = new type1(new type2(new type3(), new type4());

Cplusplus != JAVA

I wouldn't consider this to be good form in C++. It unnecessarily
complicates the code.

I'd design my objects to have small sizeof() values and let the expression
be evaluated on the stack, using copy constructors to supply the
intermediate object values needed.

However, it is 2AM here so I may reconsider later, but right now I don't
think what you are proposing is a good idea.

[Alan Johnson]

Brian Buderman wrote:

Consider the creation of a class library, where the desire is to allow
the user of the library to chain objects together during construction in
a single statement. For example, this statement uses the heap:

topLevelObject = new type1(new type2(new type3(), new type4());

This is not safe. Consider what happens if the expression "new type3()"
is evaluated, and then an exception is thrown during the evaluation of
"new type4()". (Hint: memory leak)

>
While this example only uses 4 types, in actuality there will object
trees with a much higher count. Some of the types accept abstract
interfaces, and typeinfo must be maintained such that the library can
correctly traverse the object tree. After construction of these object
trees, the user will pass them to another library object, and be done
with it.

Instead of carrying type information along with it, I suggest looking up
the Visitor pattern. It was conceived to address this recurring problem
of trying to traverse and perform actions on the nodes of a data
structure where the nodes are of varying type.

As for storage, I suggest you make use of auto_ptr. Accept the objects
as auto_ptrs and store them internally that way as well. Be sure you
either disallow or properly implement a copy constructor and operator=.
This can also help with your exception safety problem above. For each
type, add a static function that creates an object of that type and
returns an auto_ptr. Example:

class type3
{
public:
// Note: this can take parameters as necessary.
static std::auto_ptr<type3create() { return new type3() ; }
} ;

Then your tree would be built with something like:

std::auto_ptr<type1topLevelObject =
type1::create(type2::create(type3::create(), type4::create())) ;

Now, by the time "type3::create()" is evaluated, the memory that was
allocated is already being managed by an auto_ptr, so if
"type4::create()" throws an exception, it will be properly destructed.

Hope this helps.

--
Alan Johnson

[Alan Johnson]

Alan Johnson wrote:

As for storage, I suggest you make use of auto_ptr. Accept the objects
as auto_ptrs and store them internally that way as well. Be sure you
either disallow or properly implement a copy constructor and operator=.
This can also help with your exception safety problem above. For each
type, add a static function that creates an object of that type and
returns an auto_ptr. Example:

class type3
{
public:
// Note: this can take parameters as necessary.
static std::auto_ptr<type3create() { return new type3() ; }
} ;

Then your tree would be built with something like:

std::auto_ptr<type1topLevelObject =
type1::create(type2::create(type3::create(), type4::create())) ;

I forgot to take into account the pain-in-the-assness of auto_ptr when I
suggested this. Since the return value, being temporary, can't bind to
the non-const reference in auto_ptr's constructor, that last line won't
work. So either you'd have to construct it piecemeal:
std::auto_ptr<baset3(type3::create()) ;
std::auto_ptr<baset4(type4::create()) ;
std::auto_ptr<baset2(type2::create(t3, t4)) ;
std::auto_ptr<baset1(type1::create(t2)) ;

or use some other smart pointer like tr1::shared_ptr (or
boost::shared_ptr if your implementation doesn't have tr1).

--
Alan Johnson

[Daniel T.]

Brian Buderman <bu******@cisco.comwrote:

Consider the creation of a class library, where the desire is to allow
the user of the library to chain objects together during construction in
a single statement. For example, this statement uses the heap:

topLevelObject = new type1(new type2(new type3(), new type4());

While this example only uses 4 types, in actuality there will object
trees with a much higher count. Some of the types accept abstract
interfaces, and typeinfo must be maintained such that the library can
correctly traverse the object tree. After construction of these object
trees, the user will pass them to another library object, and be done
with it.

Is it best to:

a. Use pointers, and delete pointers automatically in each class
destructor (freeing user from deleting them but preventing them from
keeping a reference)

b. Use pointers, and require user to delete pointers manually (thus
killing the ability to chain the construction since a pointer to each
object now needs to be kept)

c. Use references - though I'm not sure how that would work with
abstract types...how would you pass an inline contructed derived class
reference where the abstract class reference is expected?

My inclination is to use choice a, though I know pointers are not type
safe, and I'm not sure how good of an idea it is to automatically delete
all the objects in the tree.

Thoughts?

This is strictly an issue of ownership. IMHO, the last object to send a
message to an object should also be the one that destroys it. If the
destroyer is not the same as the creator, then you must use heap ram. As
such, I think (a) above is probably the best choice.

However, there is another school of thought that is equally valid. To
them, the object that creates an object should also be the one that
deletes the object. There is much merit to this idea. It makes memory
management easer in general (though it does make factory classes a
little harder to implement,) and it allows the top level objects to
decide whether heap or stack ram should be used for a particular object.
The only reason I don't like such a scheme is that it requires the
top-level objects to hold many objects that they created but never use
themselves.

BTW, pointers are type safe.

[Mirek Fidler]

Brian Buderman wrote:

Consider the creation of a class library, where the desire is to allow
the user of the library to chain objects together during construction in
a single statement. For example, this statement uses the heap:

topLevelObject = new type1(new type2(new type3(), new type4());

While this example only uses 4 types, in actuality there will object
trees with a much higher count. Some of the types accept abstract
interfaces, and typeinfo must be maintained such that the library can
correctly traverse the object tree. After construction of these object
trees, the user will pass them to another library object, and be done
with it.

Is it best to:

a. Use pointers, and delete pointers automatically in each class
destructor (freeing user from deleting them but preventing them from
keeping a reference)

b. Use pointers, and require user to delete pointers manually (thus
killing the ability to chain the construction since a pointer to each
object now needs to be kept)

c. Use references - though I'm not sure how that would work with
abstract types...how would you pass an inline contructed derived class
reference where the abstract class reference is expected?

Thoughts?

What about "create inside" interface:

Type1 x;
Type2& t1 = x.CreateType2();
Type3& t2 = t1.CreateType3();
......

and manage resources inside Type1, Type2, Type3... (e.g. use owning
containers to implement them).

Mirek

[Daniel T.]

Alan Johnson <aw***@yahoo.comwrote:

Brian Buderman wrote:

Consider the creation of a class library, where the desire is to allow
the user of the library to chain objects together during construction in
a single statement. For example, this statement uses the heap:

topLevelObject = new type1(new type2(new type3(), new type4());

This is not safe. Consider what happens if the expression "new type3()"
is evaluated, and then an exception is thrown during the evaluation of
"new type4()". (Hint: memory leak)

While this example only uses 4 types, in actuality there will object
trees with a much higher count. Some of the types accept abstract
interfaces, and typeinfo must be maintained such that the library can
correctly traverse the object tree. After construction of these object
trees, the user will pass them to another library object, and be done
with it.

Instead of carrying type information along with it, I suggest looking up
the Visitor pattern. It was conceived to address this recurring problem
of trying to traverse and perform actions on the nodes of a data
structure where the nodes are of varying type.

As for storage, I suggest you make use of auto_ptr. Accept the objects
as auto_ptrs and store them internally that way as well. Be sure you
either disallow or properly implement a copy constructor and operator=.
This can also help with your exception safety problem above. For each
type, add a static function that creates an object of that type and
returns an auto_ptr. Example:

class type3
{
public:
// Note: this can take parameters as necessary.
static std::auto_ptr<type3create() { return new type3() ; }
} ;

Then your tree would be built with something like:

std::auto_ptr<type1topLevelObject =
type1::create(type2::create(type3::create(), type4::create())) ;

Now, by the time "type3::create()" is evaluated, the memory that was
allocated is already being managed by an auto_ptr, so if
"type4::create()" throws an exception, it will be properly destructed.

Hope this helps.

Rather than all that, how about simply using the nothrow version of new
in the OP's line above.

[Roland Pibinger]

On 18 Dec 2006 04:06:39 -0800, "Mirek Fidler" wrote:

>What about "create inside" interface:

Type1 x;
Type2& t1 = x.CreateType2();
Type3& t2 = t1.CreateType3();
.....
and manage resources inside Type1, Type2, Type3... (e.g. use owning
containers to implement them).

Better known as 'Creator As Sole Owner' pattern:
http://www.ddj.com/184409895

Best wishes,
Roland Pibinger

[Mirek Fidler]

Roland Pibinger wrote:

On 18 Dec 2006 04:06:39 -0800, "Mirek Fidler" wrote:

What about "create inside" interface:

Type1 x;
Type2& t1 = x.CreateType2();
Type3& t2 = t1.CreateType3();
.....
and manage resources inside Type1, Type2, Type3... (e.g. use owning
containers to implement them).

Better known as 'Creator As Sole Owner' pattern:
http://www.ddj.com/184409895

Thanks.

Mirek

[Alan Johnson]

Daniel T. wrote:

Alan Johnson <aw***@yahoo.comwrote:

>Brian Buderman wrote:

>>Consider the creation of a class library, where the desire is to allow
the user of the library to chain objects together during construction in
a single statement. For example, this statement uses the heap:

topLevelObject = new type1(new type2(new type3(), new type4());

This is not safe. Consider what happens if the expression "new type3()"
is evaluated, and then an exception is thrown during the evaluation of
"new type4()". (Hint: memory leak)

>>While this example only uses 4 types, in actuality there will object
trees with a much higher count. Some of the types accept abstract
interfaces, and typeinfo must be maintained such that the library can
correctly traverse the object tree. After construction of these object
trees, the user will pass them to another library object, and be done
with it.

Instead of carrying type information along with it, I suggest looking up
the Visitor pattern. It was conceived to address this recurring problem
of trying to traverse and perform actions on the nodes of a data
structure where the nodes are of varying type.

As for storage, I suggest you make use of auto_ptr. Accept the objects
as auto_ptrs and store them internally that way as well. Be sure you
either disallow or properly implement a copy constructor and operator=.
This can also help with your exception safety problem above. For each
type, add a static function that creates an object of that type and
returns an auto_ptr. Example:

class type3
{
public:
// Note: this can take parameters as necessary.
static std::auto_ptr<type3create() { return new type3() ; }
} ;

Then your tree would be built with something like:

std::auto_ptr<type1topLevelObject =
type1::create(type2::create(type3::create(), type4::create())) ;

Now, by the time "type3::create()" is evaluated, the memory that was
allocated is already being managed by an auto_ptr, so if
"type4::create()" throws an exception, it will be properly destructed.

Hope this helps.

Rather than all that, how about simply using the nothrow version of new
in the OP's line above.

Because nothrow is a false promise. It does not guarantee that no
exceptions will be thrown, only that operator new will not throw
bad_alloc. The constructor of the object being allocated may still
throw exceptions.

--
Alan Johnson