|
Boost : |
Subject: Re: [boost] [smart_ptr] scoped_array / shared_array (size_t) constructor
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2011-10-31 16:51:23
On Monday, October 31, 2011 21:20:18 Olaf van der Spek wrote:
> On Tue, Oct 25, 2011 at 12:36 AM, Olaf van der Spek <ml_at_[hidden]> wrote:
> > Hi,
> >
> > Currently, one has to manually allocate the array and pass the ptr to
> > the constructor of scoped_array / shared_array.
> >
> > boost::scoped_array<unsigned char> A(new unsigned char[100]);
> > boost::shared_array<unsigned char> B(new unsigned char[100]);
> >
> > This requires one to repeat the type and shared_array requires two
> > allocations (one extra for the control block).
> > std::vector has a constructor from size_t and one can write:
> >
> > std::vector<unsigned char> V(100);
> >
> > This avoids the type duplication and it'd allow shared_array to do
> > only a single allocation.
> > A few choices have to be made:
> > 1. Should "new T[sz]" or "new T[sz]()" be used?
> > 2. What should happen when size = 0? Should it call new T[0] or should
> > it just use NULL?
> >
> > https://svn.boost.org/trac/boost/ticket/4637
>
> Is (almost) nobody using scoped/shared_array?
I'm using it, from time to time. Frankly, I'm not sure there's much value in
the suggested improvement. Smart pointers are not containers, so there's no
need to follow the interface, especially considering ambiguities like
boost::scoped_array<unsigned char> A(0); (is 0 a null pointer or a zero size
of the array here?). Zero sized arrays are quite valid when dynamically
allocated (the allocation result is not NULL in this case), so you can't
always initialize the pointer to NULL in this case.
FWIW, I would rather prefer make_scoped_array and make_shared_array function
templates for this purpose, much like make_shared we already have. Of course,
scoped_array would have to support move semantics in order to do that. In
conjunction with auto keyword, one would not have to duplicate the array
element type.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk