Maybe Create/Destroy isn't the right solution, but there appears to be some confusion about the meaning of Get/Restore in this context. It definitely differs from VecGet/RestoreArray. For example: there is no guarantee that subsequent DAGetXXXs, punctuated by DARestoreXXXs, will give one the same object.
Dmitry. On Fri, Aug 27, 2010 at 10:02 AM, Jed Brown <jed at 59a2.org> wrote: > 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 >
