To me, intuitively (but also probably without the necessary historical context on shared_ptr design) I would think it was acceptable for us to work on, but then I wonder why is C++11's std::shared_ptr not already like this? Peter, is the right direction to implement T[] support in shared_ptr or to fix shared_array? Nate, I agree that it makes sense for any construction of one from the other to be explicit. Glen On Thu, Nov 1, 2012 at 5:32 PM, Nathan Crookston <nathan.crookston@gmail.com> wrote:
Hi Glen,
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'd definitely like that syntax best. I'd be happy to work on such a
On Thu, Nov 1, 2012 at 5:45 PM, Glen Fernandes <glen.fernandes@gmail.com> wrote: thing as well -- I'd just want to know if it's unacceptable from the start.
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>. Due to my concerns with misusing a shared_ptr to polymorphic types, I'd want such a conversion to be as visible as possible. Given the following: shared_array<int> sa(new int[500]); shared_ptr<int> sp1(sa);//1 shared_ptr<int[]> sp2(sa);//Hypothetical 2 shared_ptr<int> sp3 = static_pointer_cast<int>(sa);//3
I'd suggest 1 wasn't explicit enough (despite being explicitly constructed), 2 would be just fine, and 3 (though overloading the function might be unwise) would be fine for those that really want it.
Thanks, Nate
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost