[boost] Re: Array support [was SmartPtr (Loki) -auto_ptr/movec'torissue]

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2003-02-04 14:17:30

"Howard Hinnant" <hinnant_at_[hidden]> wrote in message
news:989D4054-37B9-11D7-9354-003065D18932_at_twcny.rr.com...
> > 1. Arrays of polymorphic objects don't work.
>
> Right.  But to me that just means you don't want to have the member
> template converting constructors/assignment in your array version of
> the smart pointer (as shown in boost::shared_ptr/shared_array, and the
> move_ptr example at
> http://home.twcny.rr.com/hinnant/Utilities/move_ptr).
>
> > 2. If I wanna arrays of monomorphic objects I can use std::vector.
>
> True.
>
> > 3. If I wanna arrays of monomorphic objects and std::vector's
> > performance
> > is unsatisfactory to me,
>
> Naw, couldn't happen! ;-)
>
> > I can use the typed buffers
> > (http://www.moderncppdesign.com/publications/cuj-08-2001.html,
> > http://www.moderncppdesign.com/publications/cuj-10-2001.html,
> > http://www.moderncppdesign.com/publications/cuj-12-2001.html) that are
> > present in the up-and-coming YASLI.
>
> Up-and-coming?  I was just getting used to "legendary"! :-)

Be afraid. Be very afraid. :o)

> > 4. So there's no reason I'd ever wanna have smart pointers to arrays.
>
> I agree that vector (or vector-like substitutes) are preferred over
> smart_ptr<T[]> in most circumstances.  But there are times when
> ownership of the array needs to be transferred or shared.  In those
> instances, vector is not a good fit.  smart_ptr<vector<T> > is a
> possibility, but this is typically inferior both in performance, and in
> client level syntax (e.g. (*p)[i] instead of p[i]).

When designing an amenity, it is important to figure out how the
alternatives work for its target audience. For the limited audience that
(1) needs a smart pointer to an array and (2) is unhappy with vector's
performance, I'd say it's ok to just advice using a SmartPtr configured
with an array deleter and have them write get_impl(sp)[45] instead of
sp[45]. The super-performance-critical code portions of an app are not that
large and much uglier for different reasons anyway :o).

Andrei