Re: [boost] shared_ptr comparison

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-08-20 01:02:55

From: Howard Hinnant <hinnant_at_[hidden]>
> And what about scoped_array?
> 
> One of the biggest reasons I see a need for scoped_array (not so much 
> for shared_array) is the ability to transfer ownership of the 
> buffer. ... Ironically, now that I look more closely at scoped_array, I 
> don't see any move semantics. :-)
> 
> Ok, what I see a need for is an array version of auto_ptr (under 
> whatever name) so that I can do something like:

Right. And though I highly respect Max's devotion to consistency,
I also dread the politics of introducing yet another version of
auto_ptr with yet another name.  It just seems easier to introduce
auto_ptr<T[n]> as a small delta to auto_ptr<T>, and it seems that
shared_ptr<T[n]> and scoped_ptr<T[n]> would be needed to fill in
the picture.

I'll also note that I dread the politics of re-introducing
shared_ptr and scoped_ptr.

And finally, the Core group "broke" auto_ptr in Tokyo, so we also
need a core language change to make it work as designed.  If we
can't get that change we need to fix the scpecification to fit
reality, or perhaps specify auto_ptr in terms of semantics with
no mention of auto_ptr_ref, and tell implementers to just "make
it so".

Fear and loathing in Redmond?

> struct LegacyBase
> {
> char* a1;
> char* a2;
> bool owns:
> 
> LegacyBase() : a1(0), a2(0), owns(false) {}
> 
> virtual ~LegacyBase()
> {
> if (owns)
> {
> delete [] a1;
> delete [] a2;
> }
> }
> };
> 
> struct MyClass
> : public LegacyBase
> {
> MyClass()
> {
> auto_ptr<char[]> r1(new char [256]);
> auto_ptr<char[]> r2(new char [256]);
> a1 = r1.release();
> a2 = r2.release();
> owns = true;
> }
> };
> 
> -Howard
> 
> On Sunday, August 19, 2001, at 02:59  PM, John Max Skaller wrote:
> 
> >  My main contention is that
> >
> > a) we should drop shared_array
> > b) we should use
> >
> > shared_ptr< array<T> >
> > shared_ptr< fixed_array<T,n> >
> >
> > instead of
> >
> > shared_ptr< T[] >
> > shared_ptr< T[n] >
> >
> > That is: don't specialise shared_ptr. Instead, make
> > first class array types for fixed length arrays
> > of both the types (1) length constant known at compile
> > time and (2) length constant bound at construction time.
> > [And use vector for (3) length variable]
> >
> > The reason is:
> >
> > 1) the first class types have uses
> > other than shared objects
> >
> > 2) there is no need to specialise shared_ptr
> > for such first class types
> >
> > I.e.: I agree with removing shared_array and using shared_ptr,
> > but suggest that instead of a specialisation, to use first class
> > array types.
> 
> Info: http://www.boost.org  Unsubscribe: <mailto:boost-unsubscribe_at_[hidden]> 
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 
>