|
Boost : |
Subject: Re: [boost] make_shared_array
From: Olaf van der Spek (ml_at_[hidden])
Date: 2012-11-01 08:48:43
On Thu, Nov 1, 2012 at 1:07 PM, Peter Dimov <lists_at_[hidden]> wrote:
> Glen has made the functions return a shared_ptr, mostly because they are
> non-intrusive and it's not possible to return a shared_array without changes
> to shared_ptr and shared_array.
Why's that impossible?
> But we can make such changes when we put the functions in Boost. So the
> question is, should we?
>
> It makes almost no sense to have a function called make_shared_array that
> does not, in fact, make a shared_array. On the other hand, Glen posits that
> some people may prefer to use shared_ptr instead of shared_array in their
> code for various reasons, one of which is that shared_array's default
> constructor can throw.
Due to the allocation of the counter? Can't that be fixed?
I'd like to see make_shared_array. I'd also like to see compatibility
between shared_ptr and shared_array where they can share the counter.
Shared_ptr should be able to point to an element of the array and
shared_array should be able to point to an array member of the object
pointed to by shared_ptr.
Wouldn't mind a variant of shared_array that knows it's size either.
Does Glen's make_shared_array have variants for both initialized and
uninitialized allocations (for builtin types)?
-- Olaf
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk