[osg-users] Returning ref_ptr<> vs. ref_ptr<>::get()

Cliff Taylor bloodgain at gmail.com
Wed Sep 10 12:34:49 PDT 2008

On Wed, Sep 10, 2008 at 2:00 PM, Robert Osfield
<robert.osfield at gmail.com> wrote:
> Hi Cliff,
> I won't dive in deep in this topic as it's been covered many times and
> there is docs up on the wiki.
> W.r.t access to .get(), yes this in theory can lead to misuse, but
> it's also key to genuine uses - such as where a C pointer is required.
>  I tend to assume that OSG users are grown ups and know how to code, I
> rather not penalise the good programmers for the inabilities of the
> few engineers who can't code their way out of wet paper bag.
> The code example you gave doesn't look clean, there is no need to pass
> back a C pointer from a function that returns a ref_ptr<>, unless the
> types of different.  Cases where the types can be different is when
> using a ref_ptr<Group> internally and then passing out a ref_ptr<Node>
> as the return type, here there is now way to downcast a ref_ptr<Group>
> to ref_ptr<Node>.  One can do this downcast use member templates,
> but... not all compilers and all the platforms we support support this
> feature so we have had to make do with out it.  Pain in the butt, but
> that's the way of the wacky C++ world.

OK, thanks.  That's about what I had figured.  Passing back the C
pointer when you're changing the reference type is the "safe" thing to
do, but it's otherwise unnecessary.

I'm still trying to decide if I agree with your statement about
"penalizing" the good programmers by having the library calls take
ref_ptr<> when they're going to implicitly cast it there anyway, but I
do see your point with .get() being a convenience to those of us who
know how to use it properly.

Speaking of which, good points were made by Paul Speed (sorry, had my
sub set to "digest..").  I can see how it would be impossible to
handle every possible result of not having access to the raw pointer
through .get().  My issue was really with the library encouraging
.get() to be used, not with it being available.

> On a general note, I tend to use ref_ptr<> when they are required, and
> C* pointers elsewhere, I choose ref_ptr<> when I want robust and easy
> memory management, I use C pointers where no particular harm will come
> from their usage, and performance will be gained (please note passing
> ref_ptr<> around introduces thrashing of the renderenceCount() which
> kills performance if you aren't careful).   Mixing code with ref_ptr<>
> and C* can be done perfectly safely, but you do need to understand the
> consequences - ref counting is one of the fundamental concepts that
> all C++ programmers need to grasp very early in their careers, long
> before they even come across software like the OSG.
> Robert.

Because of the speed requirements we have, I'll probably be using C
pointers with OSG a lot more than I would expect.
I guess the idea of using smart pointers and the practice diverge a bit.

Some version of "good library design" would say that if you are going
to use ref_ptr<>, then your library arguments should expect its use.
However, C++ brings its own issues to the party.  Also, the only way
to be sure it is always safe to pass a C pointer to the library
functions is to provide a version that takes a C pointer.  I see how
this could become an issue where someone says, "look, we're just going
to expect you to use safe coding practices" and picks a version for
the library.

It goes back to the quote:
"The difference between theory and practice is that in theory, there
is no difference between theory and practice, but in practice, there
is." -- (Unknown author)

Thanks for the fast feedback, guys :-)

More information about the osg-users mailing list