Hello Carsten, "Carsten Neumann" <[email protected]> schrieb im Newsbeitrag news:[email protected]... > Hello Johannes, > > I apologize for being slow, ..., there is no problem with the current > code: when the navigator is destroyed it decrements the ref count of the > engine, but the engine is not destroyed because the client code still > has a reference to it - am I missing something? > Aren't calls to new and delete then still in a different context? Imho, this route won't work. It would work if subRef would be inlined and I would be at the terminal end of the lifetime of the engine object. But if some other part of the framework would have a reference to the object it would be doomed.
> > You still need to make sure the Navigator is destroyed before the > engine, but that is true anyway, since destroying the engine while it is > still in use by the navigator is not good ;) > Yes. > > Maybe the part that is not clear here is that our RefCountPtr does work > with objects derived from MemoryObject (I'll make sure the correct > typedefs are added if they are currently missing). If you absolutely > want to use boost::shared_ptr instead of our smart pointers you need to > use a custom deleter to make sure the ref count gets decremented > (<http://www.boost.org/doc/libs/1_40_0/libs/smart_ptr/sp_techniques.html#intrusive> > has an example for this type of thing). > No, the point is not that I want to use the boost smart pointers. I'm fearing only the pitfall around. But see below... >> I actually do not have this memory problem in my code, since I do use the >> same memory management strategy for all of the dynamic link libraries and >> the base application. My point is a matter of prinicple, that it must be >> generally assured that all objects are destroyed in the same context >> (dll) >> in which they originally were heap constructed. > > hm, that seems to imply that anything that touching memory is a no-no > for inlining and so is using std::vector<>::swap()? > Yes, this is one of the pitfalls. >> It can't be generally >> assumed that the same memory handlers are at work in all dlls. Of course >> such a principle could be ruled out by explicitly demanding consitent >> memory >> managment for all involved parties. > > I somehow doubt that this is going to work with OpenSG (at least out of > the box) and it sounds extremely difficult (or at least tedious) to > ensure for larger applications/libraries. Yes it is. Once we have started to customize the memory backend we run in all sorts of these problems. On the other hand the default memory backend is not suitable for our purposes. > Is there some way to check for this sort of problem or does one have to > wait for nasty surprises at runtime? I fear so... Ok, after thinking about it, I come to the pragmatic conclusion, that it can't work without demanding the same memory backend for the client and the framework. Using something like boost shared_ptr would help with the navigator stuff but the stl inline stuff would remain as a problem. 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
