Hi, On Thursday, August 01, 2013 06:21:10 Robert Osfield wrote: > The OSG doesn't have or use an equivalent to std::shared_ptr<>, and if > I were to write a new scene graph tomorrow I would not use a > std::shared_ptr<> for general nodes in the scene graph. shared_ptr<> > isn't as robust as ref_ptr<> in general usage as you are forced to use > a single shread_ptr<> group to reference a single object, you can't > just assign a C pointer to a node and create your own shared_ptr<> to > it as it breaks the design and you'll end up with dangling pointers. > This design problem with shared_ptr<> forces you to copy > shared_ptr<>'s all the time when access data members which just can't > be efficient and requires end users to always stick to this rule. Ack! Also you need twice as much mallocs because the reference counts need to be allocated seperately.
> It's a shame that intrusive_ptr<> isn't part of the standard. That's does not help too much. I have for a different project a weak pointer that is thread safe with the clear and easy semantics of std::weak_ptr with an embedded reference count and sadly I never found a way to implement the same semantics using intrusive_ptr. And to be honest, this small helpers are so small and easy to do that I don't mind havind this in a project. The more problematic part is the atomic count itself that used to be highly architecture dependent. But now the current standard contains std::atomic. If I should start today with anything new, I would use std::atomic and build on top of that. Greetings Mathias _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
