On Wed, Sep 10, 2008 at 2:00 PM, Robert Osfield <[EMAIL PROTECTED]> 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 :-) _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
