Subject: Re: [boost] make_shared_array
From: Glen Fernandes (glen.fernandes_at_[hidden])
Date: 2012-11-02 11:36:27
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.
On Thu, Nov 1, 2012 at 5:32 PM, Nathan Crookston
> Hi Glen,
> On Thu, Nov 1, 2012 at 5:45 PM, Glen Fernandes <glen.fernandes_at_[hidden]> wrote:
>> 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
> thing as well -- I'd just want to know if it's unacceptable from the
>> 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
> 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
> shared_array<int> sa(new int);
> 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.
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk