Archived

This topic is now archived and is closed to further replies.

Good programming practice?

This topic is 5965 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

In my class hirearchy, there is a general "composite" class that can dynamically attach other child "composites" or "primitives" to itself, thus forming an implicit tree-type structure. I want to be able to attach both stack-allocated and heap-allocated (e.g. both class/local variables and dynamic variables) to these composites. The problem I run into, though, is when attaching unnamed, dynamic objects. They must be destroyed eventually. The problem is when and by whom. Here are my solutions: 1) I could track all dynamic objects externally to the composite class, but that would be extra overhead, being that the composite class already tracks it. Deciding when to destroy them would be a similarly silly, duplicated task. 2) I could include a boolean flag in the attach function to state whether or not the attaching object should be dynamically destroyed when the composite object is destroyed, but that''s too much special-case work for this hirearchy, I feel. 3) I could just try to destroy all of the attached objects when the composite object is destroyed, catching all exceptions raised from trying to delete a non-dynamic object. Though I feel 2 is the most correct, I''ve decided to go with 3 because it has the least global overhead. I feel that it''s bad programming practice, though, and it abuses the try-catch paradigm much in the same way that most people complain about. Any comments or suggestions? Thank you for your bandwidth. -- Succinct ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Share this post


Link to post
Share on other sites
quote:

They must be destroyed eventually. The problem is when and by whom.



Memory should be released by the same object that allocates it IMHO. If this is some kind of object manager/memory manager class, then perhaps you should extend its functionality to some kind of factory object so that any dynamically created objects are automatically created through this object (overloading new for example). If not, then I think the best solution to this problem is to simply avoid it... Let whoever is attaching stuff to this object be responsible for deleting it afterwards...

Share this post


Link to post
Share on other sites
Yes, you''re right, I''ll probably have to implement a factory of some sort. Still, a factory would only solve who destroys the objects, not when they''re destroyed. I''m not really a fan of garbage collection, but I think it would be necessary for a factory of this type, i.e. walking the list of previously attached object to see if they''re still attached.

I was also thinking that maybe I could just require that all objects are created dynamically. It works for borland... I think I need some real-application testing for this hirearchy to see what will work best.

Thank you for your bandwidth,
-- Succinct

Share this post


Link to post
Share on other sites