Hello Carsten, "Carsten Neumann" <[email protected]> schrieb im Newsbeitrag news:[email protected]... > Hello Johannes, > > 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?
>> 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." >> 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). Did you (OpenSG core team) think more about a general usage of the boost::shared_ptr for non FieldContainer parts of the framework? Actually, OpenSG already uses parts of boost, which is imho a strength of the framework. Best, Johannes ------------------------------------------------------------------------------ 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
