Re: [boost] shared_ptr comparison

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.