Hi Robert,

I understand your point of view and agree adding too much ref_ptr<>s can affect 
performance. Well I'll keep that in mind for future submissions!
And about scoped_array... I just pray for having these (and much more) in C++ 
standard soon! ;)

Thanks for merging.
See you soon for another submission!

BTW, what is the status of proxy images? (I don't remember!)

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/

----- "Robert Osfield" <[email protected]> a écrit :

> 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
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org

Reply via email to