On 1/16/07, Nathan Bates <[EMAIL PROTECTED]> wrote:
> I'm certainly confused. Is it simply that you don't like doing a
> .get() when passing in an object?
Yes, exactly.
To me, get() implies the criminal act of circumventing
reference-counting to get a raw/direct C pointer to an object
which then becomes vulnerable to being deleted.
It would be true if ref_ptr was the class that contains the ref.
counting data (ie like boost::shared_ptr) it does not. The object
itself contains the ref. counting data. So when you construct a new
ref_ptr from an existing pointer, you can continue from where you left
of (not so with boost::shared_ptr). What I mean is this...
boost::shared_ptr<SomeObject> so1 = new SomeObject();
boost::shared_ptr<SomeObject> so2 = so1.get();
In this code, so1 and so2 points to the same object and the ref count
of both pointers is 1 and a double deletion will occur, as you
mentioned. But
ref_ptr<SomeOSGObject> soo1 = new SomeOSGObject();
ref_ptr<SomeOSGObject> soo2 = soo1.get();
In this code, soo1 and soo2 points to the same object and their ref.
count is 2 not 1. No double deletion will occur. The ref. count data
is carried around with the object not with ref_ptr. (thats why
OSGObject needs to derive from Referenced class), boost::shared_ptr
does not have this restriction but then it needs to carry its data
around itself causing other limitations.
You can think of ref_ptr as just a convenience wrapper around
Referenced::ref and unref, nothing more. (its like
boost::intrusive_ptr).
I hope this answers your questions.
--
Orhun Birsoy
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
