Hi Sukender, On Mon, Jan 11, 2010 at 4:00 PM, Sukender <[email protected]> wrote: > Well, maybe left/right files were inverted during comparison?
I can only think that's what I did, as I normally have the changed file on the left, original file on the right. Although I would have thought I would have picked that up as new about the introduced of the ref_ptr<> being your change... > Anyway, I'm glad to see it's okay. Most of the time I get there in the end :-) > And about RAII, you're right: there are thousands of lines to be changed the > same way... It's a long-term task! Actually I'm not to worried about putting ref_ptr<>'s everywhere, in fact, in many places I absolutely don't want to use them in the OSG for efficiency reasons, and if you know what you are doing ref_ptr<>'s don't always add extra safety w.r.t memory management. If you expecting threading issues or exceptions being thrown then the need for ref_ptr<> goes up. For general users I'd recommend "if in doubt use a ref_ptr<>" or "always use a ref_ptr<> unless your are 100% certain it's safe". As the author of the OSG's ref counting and smart pointers I should be able to spot the times when it's OK to just use C*'s with the OSG, so I'm quite happy to make a decision on a case by case basis. > I've replaced the new/delete with scoped_array<> (auto_ptr<> was a good idea, > but it does not support arrays), and added .valid() / .get() calls. I just > hope scoped_array<> won't conflict with next C++ standard(s) (in TR2?), or > else we'll need to add a native support detection. > Here is the file, against rev. 10939. These changes look good, now merged and submitted to svn/trunk. You did miss the other new [] that wasn't cleaned up, so I've added the use of scoped_array here as well. Although I can't help feel that scoped_array itself is a bit of overkill for replacing two lines of delete []; just on the basis that it's robust in the presence of a possible exception... one has to wonder about the now having to maintain scoped_array as it has many more lines of code that could be potentially buggy or non portable. In boost we trust I guess :-) Robert. _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
