Hi, sorry for the general delays, travelling, catching up,
On Tue, 2010-02-23 at 13:56 -0600, Dirk Reiners wrote: > Hi Gerrit, > > Gerrit Voß wrote: > > > > hmm there was some intention in using a different thing and not calling > > the pointers XXXRefPtr for the FieldHandles as they are for very short > > lived local use only, for example they do not keep the container behind > > them alive. So I did/do not want to get them to close to the mechanisms > > we use for storage. > > > > Similar I do/did not want them derived from MemoryObject as elements > > derived from it are intended to be stored, which FieldHandles absolutely > > are not meant to. > > Well, does it make a functional difference? > > > I see the point with the performance. > > > > So if we switch to using intrusive counting for performance reasons I > > would like to keep the names different from what we use for the rest > > where storage is intended, e.g. I would more tend to keep using XXXPtr > > instead of XXXRefPtr. Ideally I would not have Ptr anywhere in there, > > in the end I used it because I needed to cast them, so maybe we should > > rethink this and complete switch away from naming them Ptr. > > > > Similar I would prefer to put the intrusive counters directly into the > > base class and not have them derive from MemoryObject. > > Do MemoryObjects have any kind of overhead compared to direct intrusive > pointers? I didn't think so, but I might be missing something. > > If they are essentially the same I don't really see the point of adding > another set of reference counting mechanisms. If you're > worried about the confusion with persistent vs. transitional storage, maybe > we need to rename MemoryObject to RefCountBase, but > other than that I'd prefer to not introduce something new unncessarily. As said technically it is a non issue. It's a style thing, basically where would you prefer the handles to pop up in the class hierarchy. For the very few lines of code involved and our chronic lack of proper documentation I tend to keep them separate. But if it bothers you change it. kind regards gerrit ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
