YetiSim Blog

A new class for memory management has been implemented for YetiSim, which is going to replace boost::shared_ptr.  This class has not yet been added to SVN.  I am migrating existing code to use the new MemoryManager singleton, and the design of the classes are being adjusted as I go along.  Rather than committing a broken YetiSim to trunk, or branching, I’ve decided to just do all the changes locally and introduce them all at once.

This represents a major change to YetiSim, since the class design is solidifying.  Real destructors are to be implemented, and new / delete calls are entirely confined to the MemoryManager class.  The library interface will consist entirely of references, while internal operations will use pointers or references.  The introduction of the MemoryManager has forced me to reconsider memory management for each class, and carefully document assumptions that have been made.  I read an analogy somewhere (maybe Meyers, maybe some docs, don’t remember) that dealing with memory is like dealing with toxic chemicals.  They are sometimes essential, however they must be treated with care.  I like this analogy, and I think about it a lot while I code.

Don’t get me wrong, boost::shared_ptr was very useful at the time, and perhaps my ignorance of Boost smart pointers is part of the reason I have migrated back to relatively simple references and pointers.  The use of smart pointers helped me create an initial version of YetiSim, and execute some simple simulations.  They were very useful for prototyping, and I feel that the overall quality of YetiSim has benefited from my experience with them.  But I also believe that they belong outside of the YetiSim library at a user level for now, and even then users must be careful of performance pitfalls.  The low overhead of boost::shared_ptr becomes astronomical in very large systems, with constant pointer operations.