heap vs. stack | | |
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.
| | | | re: heap vs. stack
On Sun, 17 Dec 2006 23:18:25 -0500, Brian Buderman wrote: Quote:
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. | | | | re: heap vs. stack
Brian Buderman wrote: Quote:
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) Quote:
>
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 | | | | re: heap vs. stack
Alan Johnson wrote: Quote:
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 | | | | re: heap vs. stack
Brian Buderman <buderman@cisco.comwrote: Quote:
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. | | | | re: heap vs. stack
Brian Buderman wrote: Quote:
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 | | | | re: heap vs. stack
Alan Johnson <awjcs@yahoo.comwrote: Quote:
Brian Buderman wrote:
Quote: Quote:
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)
> Quote:
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. | | | | re: heap vs. stack
On 18 Dec 2006 04:06:39 -0800, "Mirek Fidler" wrote: Quote:
>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 | | | | re: heap vs. stack
Roland Pibinger wrote: Quote:
On 18 Dec 2006 04:06:39 -0800, "Mirek Fidler" wrote: Quote:
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 | | | | re: heap vs. stack
Daniel T. wrote: Quote:
Alan Johnson <awjcs@yahoo.comwrote: Quote:
>Brian Buderman wrote:
> Quote: Quote:
>>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)
>> Quote:
>>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 |  |
| | |  /bytes/about
We are a network of experts and professionals in IT and software development that help one another with answers to tough questions and share insights.
Get the best answers to your questions from over 226,272 network members.
|
