Hi Tim, On Saturday 11 July 2009 09:28:21 Tim Moore wrote: > > Vote against. > > You will need two allocations for a new object that is used with the the > > std::shared_ptr implementation - one for the object and one for the > > reference count. I like to use that SGReferenced stuff for many small > > lightweight objects > > Note that I said "and its cousins." I had thought that TR1 includes boost's > intrusive_ptr, but now I see that it doesn't. No matter; it is in boost and > available. This wouldn't replace your implementation of SGReferenced or > osg::Referenced, but simplifies access to them by clients who wouldn't have > to care about the specific type of the reference-counted object. The only thing in tr1 is the shared_ptr/weak_ptr. I am Not sure what tr2 includes. What I am missing in the intrusive pointer is a thread safe implementation of the weak_ptr. Note that we already have that in simgear ... Not yet thought about that, but is there any chance to implement the weak_ptr semantics together with the intrusive_ptr?
> Again, I'm not proposing getting rid of SGReferenced; I'd just like a > unified way to use different pointer implementations. Ok, I see. But, at least to me it was never a big problem to distinguish between fg/sg classes and scenegraph classes. So scenegraph means osg::ref_ptr and fg/sg means SGSharedPtr. And from an abstraction point of view osg* usage should not be visible too much. Those places where this rule is broken is something I do not like either. As already told, I believe that it is not a good idea to tie a simulation to a viewer framework. And a scenegraph is nothing more than that ... Greetings Mathias ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
