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.

        Dirk

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

Reply via email to