Comments for the article 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 );

I am not sure if my method is any good.. I just allowcate a big heap, and write a class to allocate/deallocate memory from this giant heap... and garbage collect when needed..

This is perhaps off topic.. how do u guys overcome the problem of memory fragmentation after a few "new" and "delete"..?

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.

One of the most crucial things that a game engine must do is efficient garbage collection. Therefore a system where the engine owns every object and does NOT perform refcounting is problematic. The proposed solution would be much better if ref-counting support was added to the engine. In one of my projects I had a singleton memory tracker and each core object would register itself the the memory tracker in it''s constructor and de-register itself in it''s destructor. Then I was able to eximine the contents of the memory tracker upon program completion to see which objects were not being deleted as expected.

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????