The Power of the Creator

Very interesting approach...

It sounds very much like the factory-worker design pattern, which is essentially a singleton derivative anyway, is it not?

Thanks for the article, good read.

Robert Dick
Gadget-Games

Well, it''s not a singleton, you create lots of meshes and sounds. It''s a class factory deviation that garuntees only the class that is supposed to create and destroy instances can. Typically a class factory''s responsiblity ends after the object''s created. Is that what the factory-work is?

...
Two other methods I know of to keep tabs on things, are resource managers and reference counting. The resource manager creates and destroys everything, and hands out handles to the objects. Similar to the way files work; you open it and get a handle, then use that handle to do stuff. With reference counting, each objects keeps track of how many people are pointing to it, and when it falls to zero it deletes itself. You need to use a smart pointer with reference counting in order to ensure all the rules are followed correctly.

Have you ever used these methods? How do they compare to what you implemented?



Magmai Kai Holmlor
- Not For Rent

i did encounter this problem before.. my solution was to build a repository of pointer''s and point them to every object i created dynamically..

at the end of the program, i just check my repository of pointers and delete each non-null pointer..

kinda like grouping up smart pointers..

class Object { void addref(Object * pObject) { // add this pointer to the repository } } class myclass : public Object { myclass() { addref(this); } } class Repository { void delete() { // check if pointer is not null, then delete it } ~Repository() { delete(); } }

i have to go class now, later i will edit this
post with an implementation for the repository and object

{ Stating the obvious never helped any situation !! }

Yes, all of those methods would also work to eliminate memory leaks, and I did look into a few of them, but I ended up using my method for several reasons.

First, it is NEVER NECESSARY for the user of my library to delete ANYTHING related to it. Therefore, there is no ambiguity, and it protects the client programmer. They couldn''t create a new one and delete it if they tried , because I made the constructors AND destructors protected or private.

Second, I''m allowed to pass pointers everywhere in my program. I pass pointers to objects all over the place; many of my GUI items have pointers to sounds that go off when they are clicked. Some sounds or sprites or textures have dozens of pointers to them at a time, but nobody ever wonders whose job it is to clean up afterwards.

Third, there is no ambiguity in what order to delete objects. My engine class ensures that all objects are deleted in the correct order; that is, no sounds are deleted after I release DirectSound, and no vertex buffers are released after I release DirectGraphics. This ensures neat cleanup.

Fourth, this allows me to save on memory. Everything that will create or destroy an object must go through one specific place in my engine. My parent Engine class keeps track of every file that was ever used as a resource for sound, textures, fonts, or anything else. When someone asks for a something from that same file, I can simply return a pointer to the first object that was loaded and be done with it. Obviously this is not reasonable in all cases, but it works wonders for sounds and textures and fonts.

Thanks for the feedback, guys.



~BenDilts( void );

Your method is fine for ensuring no memory leaks and such, but it still does not solve the problem of who owns things. There are many application specific ownership issues that should be resolved, and while it is nice to have this method to fall back on, higher level ownership is still needed. Say for example, that a world is continuous and chunks are phased in and out at the boundaries. Objects should be loaded when necessary, and unloaded when extremely far away. This hands object control over to the level of detail, world system. There are other good examples also.

MR. dilts is a fantabulous writer... all of your articles have been most educational.
if i could trouble this fantasmonious community for one more bit of knowledge, i will not bother anyone for at least a week...

what does lol mean????

Hi and thanks for this nice article. However one questions stays:
Say, you have a linked list that is embedded in a wrapper class. (For example a StringList object that allows you to add/delete/exchange and sort strings to keep them in a certain order.) The objects are linked together by the wrapper. (In my example those are structs, containing the string itself and Prev/Next pointers.)
The question: Who owns the elements of this list.

My answer: the Wrapper!

Well, to the real question: Say, those objects are WAY more complex so it is possible to retrieve pointers to them in order to manipulate them directly (not through the wrapper). Furthermore say, the structure is not only a linked list but a tree. To ease building the tree up every member of the Tree has a AddLeft() and AddRight() function that allows to directly add nodes to the tree.

The REAL question: Who owns those elements now? The Wrapper? For all the objects are "wrapped" by it? Or the nodes? For they can create the childs themselves?

This is possibly a question of view on the things, so no solution might be right, but please state what you think about it ...

Thanks ...Hagen!