Hi Jeff,
If a class derived from Referenced has a public destructor
it would be possible to create an object on the stack. It could be an
automatic variable in a function call. A pointer to one of
these objects could be assigned to a ref_ptr. One of two bad things
will happen. First, if the ref_ptr goes out of scope it will try to delete
the object on the stack. Calling delete on something that wasn't
allocated with new. Second, if the object on the stack goes out of scope
(i.e. returning from the function call) the ref_ptr now has an invalid
pointer. The later is usually harder to find.
Avoiding these pitfalls by simply protecting the destructor
of a class derived from osg::Referenced is "good
practice".
From: Don Burns [mailto:[EMAIL PROTECTED]
Sent: Monday, August 21, 2006 4:04 PM
To: osg users
Subject: Re: [osg-users] Event handler memory leak...
On 8/21/06, Jeff
Kershner <[EMAIL PROTECTED]> wrote:
The reason for doing this actually falls into the category of "good practice". Using a protected destructor makes it impossible to create the object on the stack, forcing you to allocate it on the heap.
I read this in the Delta3D docs and never understood why.
Delta3D mentions that:
Destructors for subclasses of dtCore::Base must have protected destructors. Otherwise use of RefPtrs will cause some serious problems if the objects are allocated on the stack.
So why is this?
The reason for doing this actually falls into the category of "good practice". Using a protected destructor makes it impossible to create the object on the stack, forcing you to allocate it on the heap.
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
