From: Ralf W. Grosse-Kunstleve (rwgk_at_[hidden])
Date: 2006-03-09 14:24:50
--- Peter Dimov <pdimov_at_[hidden]> wrote:
> Ralf W. Grosse-Kunstleve wrote:
> > --- Dan Day <coolmandan_at_[hidden]> wrote:
> >> On 3/8/06, Ralf W. Grosse-Kunstleve <rwgk_at_[hidden]> wrote:
> >>> Are there arguments for not adding release()?
> >> Check the FAQ on the scoped_ptr documentation.
> > Policing arguments ("you shouldn't to this") are OK only if there is
> > an alternative. As I wrote before, there is no auto_array, therefore
> > the FAQ is just frustrating.
> I'm willing to add scoped_array::release if nobody objects and if you
> contribute a test. But keep in mind that 1.34 is closed for new features.
In the meantime I implemented auto_array, starting with the scoped_array
For the future, eventually the same file should show up here with version
In contrast to the STLport implementation I use this approach to implement the
copy constructor (and similarly for the assignment operator):
mutable T* ptr;
auto_array(auto_array const& other)
ptr = const_cast<auto_array*>(&other)->release();
I know it works on a large number of platforms (several versions of EDG, VC,
g++). valgrind also didn't have any complaints. Is the approach also OK from a
theoretical viewpoint? Or is it necessary to adopt the more involved STLport
approach of introducing an auto_ptr_ref with a common base class for auto_ptr,
I'd be happy to contribute my version back to boost. Then the FAQ wouldn't be
frustrating anymore and scoped_array could stay as is.
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk