On Fri, 27 Aug 2010 09:45:36 -0500, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote: > I think DAGetXXX etc should really be thought of as constructors, > that under the hood manage a pool to amortize the construction time. > Perhaps more precisely, DA acts as a factory. > It would be natural to rename them DACreateXXX, except that > then XXXDestroy is the wrong thing to do (unless the destructor > is overloaded in the corresponding object).
Hmm, I think there is an important distinction, in terms of overall memory use, between objects that live a long time and those that do not. I might allocate a bunch of memory in a preprocessing stage, release it, and then build solver objects. If all that preprocessing memory stayed alive for the life of the program, I would run out of memory. You can't overload Destroy in place of Restore unless you maintain upward links or guarantee that the managing object will never need to do anything when you restore. One way to do this would be to double-reference "gotten" objects and consider them to be checked in any time the reference count drops to 1. But this excludes more elaborate data structures and extra consistency checks. I don't see any great nastiness of Get/Restore for managed objects and Create/Destroy for objects that the user wants to own. Jed