Hello Carsten, "Carsten Neumann" <[email protected]> schrieb im Newsbeitrag news:[email protected]... > > for example ChangeList, classes of the Collada and OpenGFLight loader, > TextFace, GraphOps, ... > Ah I see...
> > 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. >> 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'. > > 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. 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. 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
