Hello Johannes, Johannes Brunen wrote: > "Carsten Neumann" <[email protected]> schrieb im > Newsbeitrag news:[email protected]... >> hm, seems like it is a useful property, but how do they achieve that? >> > I'm no expert for this but I think that the trick is that the shared_ptr > implementation uses virtual functions in the sp_counted_base class that gets > generated in the factory dll since it is a template instantiation.
the reason I keep asking is that I've not fully understood what exactly boost::shared_ptr does different from our smart pointers when it comes to object deletion. >>> 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... > Sorry, don't misunderstand me. My point is that the Navigator class should > manage only the internal engine objects, which it has created itself. The > user defined engine object on the other hand should then be managed by the > client code, which has actually responsibility for it. The client code could > simply hold the engine object in a smart pointer for lifetime management. > This was what I meant by 'simple to do'. I apologize for being slow, but it seems to me if you do what you describe in your last sentence (client code creates the engine and uses a smart pointer to keep it around), 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? 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 ;) 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). >> 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? > 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()? > 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. Is there some way to check for this sort of problem or does one have to wait for nasty surprises at runtime? 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
