Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > heap vs. stack

Reply
Thread Tools

heap vs. stack

 
 
Brian Buderman
Guest
Posts: n/a
 
      12-18-2006
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.
 
Reply With Quote
 
 
 
 
noone
Guest
Posts: n/a
 
      12-18-2006
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.


 
Reply With Quote
 
 
 
 
Alan Johnson
Guest
Posts: n/a
 
      12-18-2006
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<type3> create() { return new type3() ; }
} ;

Then your tree would be built with something like:

std::auto_ptr<type1> topLevelObject =
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
 
Reply With Quote
 
Alan Johnson
Guest
Posts: n/a
 
      12-18-2006
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<type3> create() { return new type3() ; }
> } ;
>
> Then your tree would be built with something like:
>
> std::auto_ptr<type1> topLevelObject =
> 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<base> t3(type3::create()) ;
std::auto_ptr<base> t4(type4::create()) ;
std::auto_ptr<base> t2(type2::create(t3, t4)) ;
std::auto_ptr<base> t1(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
 
Reply With Quote
 
Daniel T.
Guest
Posts: n/a
 
      12-18-2006
Brian Buderman <(E-Mail Removed)> 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?
>
> 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.
 
Reply With Quote
 
Mirek Fidler
Guest
Posts: n/a
 
      12-18-2006

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

 
Reply With Quote
 
Daniel T.
Guest
Posts: n/a
 
      12-18-2006
Alan Johnson <(E-Mail Removed)> wrote:
> 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<type3> create() { return new type3() ; }
> } ;
>
> Then your tree would be built with something like:
>
> std::auto_ptr<type1> topLevelObject =
> 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.
 
Reply With Quote
 
Roland Pibinger
Guest
Posts: n/a
 
      12-18-2006
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
 
Reply With Quote
 
Mirek Fidler
Guest
Posts: n/a
 
      12-18-2006

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

 
Reply With Quote
 
Alan Johnson
Guest
Posts: n/a
 
      12-18-2006
Daniel T. wrote:
> Alan Johnson <(E-Mail Removed)> wrote:
>> 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<type3> create() { return new type3() ; }
>> } ;
>>
>> Then your tree would be built with something like:
>>
>> std::auto_ptr<type1> topLevelObject =
>> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How much heap can I reserve for JVM? Error when allocation very much heap Raymond Schanks Java 0 04-11-2010 04:25 PM
C/C++ compilers have one stack for local variables and return addresses and then another stack for array allocations on the stack. Casey Hawthorne C Programming 3 11-01-2009 08:23 PM
stl heap question: restoring heap validinty after changing 1 element viki C++ 6 06-28-2008 10:12 AM
Heap dump file size vs heap size Michal Slocinski Java 1 03-25-2008 12:54 PM
stack and heap question joe Java 3 08-05-2004 08:24 AM



Advertisments