Hi Nate, I have desired shared_ptr<T[]> for a while now; if it is considered appropriate for shared_ptr to support that I would like to help make that happen. My functions could be provided as just allocate_shared<T[]> and make_shared<T[]> in that case. I agree that while named "make_shared_array" and "allocate_shared_array" they should really return shared_array<T>. I also like the suggestions Peter had to fix shared_array (e.g. nothrow construction) and perhaps to allow obtaining a shared_ptr<T> from shared_array<T>. Glen On Thu, Nov 1, 2012 at 10:04 AM, Nathan Crookston <nathan.crookston@gmail.com> wrote:
Hi Peter & Glen,
On Thu, Nov 1, 2012 at 6:07 AM, Peter Dimov <lists@pdimov.com> wrote:
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.
I agree that make_shared_array should return a shared_array. I would much rather see shared_array improved to allow such an allocation strategy -- I patch my local copy to have an aliasing constructor & an implicit conversion to const. A non-throwing default constructor would be very welcome too.
I don't like the idea of returning shared_ptr due to concerns with implicit conversion from derived to base. Also, the lack of operator[] would make such usage unnatural (perhaps Glen uses a patched shared_ptr?)
The only way I'd want a shared_ptr returned is if shared_ptr were partially specialized like unique_ptr -- i.e., I could write shared_ptr<int []>. (Not to go OT, but would a (presumably large) patch with this change be considered?)
Thanks, Nate
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost