On Thu, Nov 1, 2012 at 1:07 PM, Peter Dimov <lists@pdimov.com> 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