Hello Johannes, Johannes Brunen wrote: > "Carsten Neumann" <[email protected]> schrieb im > Newsbeitrag news:[email protected]... >> NavigatorEngine derives from MemoryObject out base type for ref counted >> objects (that are not FieldContainer). The navigator only decrements the >> ref count in its d'tor. >> > I see... >> How does this work for all the other ref counted objects? >> > Which one are you speaking about?
for example ChangeList, classes of the Collada and OpenGFLight loader, TextFace, GraphOps, ... >>> Is it possible to handle the NavigatorEngine objects by boost shared >>> pointers inside the Navigator, which (imho) do not show this problem? >> hm, how would that be any different? Even if you use a custom deleter >> (not sure if that is the right boost terminology) it would still execute >> from the Navigators d'tor. >> > I do not speak about the shared_ptr custom deleter. If you create the boost > shared_ptr inside of the OpenSG dynamic link library and share it with the > client code there is no problem with the deletion. Similar, if the client > code build up the shared_ptr and handles it to the OpenSG library the > deletion should also be no problem. > > See also: > http://www.boost.org/doc/libs/1_40_0/libs/smart_ptr/sp_techniques.html#abstract > "A key property of shared_ptr is that the allocation, construction, > deallocation, and > destruction details are captured at the point of construction, > inside the factory function." hm, seems like it is a useful property, but how do they achieve that? >>> Another possibility would be to not manage the lifetime of the user >>> defined NavigatorEngine objects but leave it in the client code. >> Perhaps your client code can keep a reference to the NavigatorEngine and >> you could make sure that it is only given up after the Navigator itself >> is destroyed? >> > Yes, but this is cumbersome. I then would prefere a solution in which the > Navigator does not handle a reference to the user defined engine, i.e. the > client code must handle this completely (which is simple so). uhm, IMHO this sounds like the opposite of simple and not-cumbersome to me... > Did you (OpenSG core team) think more about a general usage of the > boost::shared_ptr for non FieldContainer parts of the framework? no, not recently. Currently they are (only?) used with the FieldHandles and regularly show up high in profiles when you run things like GraphOps that change or read many fields in a very generic fashion, so personally I'd rather get rid of that use too and derive FieldHandle from MemoryObject to get a built in ref count. One thing we could do to avoid creation/deletion of MemoryObject derived types in a different fashion is hide the c'tors (for 1.x compatibility this is currently not the case everywhere) and add static create() functions. That would move creation and destruction into OpenSG. Would that help with your situation? Other than that I'm still interested in understanding how boost::shared_ptr achieves what you need, perhaps we can duplicate that property? Cheers, Carsten ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
