Boost logo

Boost :

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

"Howard Hinnant" <hinnant_at_[hidden]> wrote in message
> > 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
> > 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
> > (,
> >,
> > 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).


Boost list run by bdawes at, gregod at, cpdaniel at, john at