From: Howard Hinnant (hinnant_at_[hidden])
Date: 2001-08-19 14:44:36
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:
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.