Thanks for the tips everyone. I suppose as Paul suggests, it's best to avoid doing things that hurt. The problem is that when we accidentally implemented this pattern in a more complex application, it was a bit fiddly to track down. I only noticed the problem because of the memory leak that resulted from it. I suppose the lesson I learn is that I need to be more careful when using ref_ptr than blindly applying it to every Referenced object whose lifetime is less than obvious to me. Which I have to confess, was my previous rather flawed logic. Chris.
Date: Tue, 18 Nov 2008 10:56:03 -0700 From: "Paul Martz" <[EMAIL PROTECTED]> Subject: Re: [osg-users] A very simple ref_ptr memory leak example. To: "'OpenSceneGraph Users'" <[email protected]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" > Using ref_ptr's is far cheaper than a garbage collector we > don't have (... until ISO C++ 2009 ?). > osg::observer_ptr<> could be used to solve the problem, but > you can also simply try to avoid circular references... how ? > Well, you could try to define an object to be "slave" of > another one. For instance, if 'B' is slave, then A has a > ref_ptr<> to B, and B has only a raw pointer (A*). In most > cases it's enough because the raw pointer is used only when A > is allocated. That's how I'd handle it. The posted code would behave the same for any type of reference-counted memory management system, I imagine, so isn't really an issue with OSG ref_ptr<> classes. It's simply an aspect of the algorithm, which programmers must be aware of and be careful to avoid. Or, to put it another way: "I went to the doctor and said, 'hey doc, it hurts when I do this' and he replied 'don't do that'". :-) -Paul _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
