--- Peter Dimov <pdimov@mmltd.net> wrote:
Ralf W. Grosse-Kunstleve wrote:
--- Dan Day <coolmandan@gmail.com> wrote:
On 3/8/06, Ralf W. Grosse-Kunstleve <rwgk@yahoo.com> 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 implementation: http://phenix-online.org/cctbx_sources/scitbx/include/scitbx/auto_array.h For the future, eventually the same file should show up here with version history: http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/ In contrast to the STLport implementation I use this approach to implement the copy constructor (and similarly for the assignment operator): class auto_array { 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, auto_ptr_ref? 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. Cheers, Ralf __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com