Re: [boost] (RFC) make_shared name change

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-14 12:12:33

"Peter Dimov" <pdimov_at_[hidden]> writes:

> From: "Daniel Frey" <daniel.frey_at_[hidden]>
>> Peter Dimov wrote:
>> >
>> > make_X(args) is typically equivalent to X<...>(args). However,
> make_shared
>> > is not equivalent to the corresponding constructor. The constructor
> throws
>> > an exception when the argument has expired(), and make_shared returns an
>> > empty shared_ptr.
>>
>> Which is surprising, at least to me. OK, I'm sure it's documented, but
>> documentation aside the code (and the interface) should speak for
>> itself. You seem to think that the function's name is the reason for
>> this surprise, but I don't think that any name will do in this case.
>
> Perhaps, but some names are "less bad". It is a convention that make_* names
> are constructor aliases; this is not the case here, so I conclude that
> make_shared isn't a particularly good choice.
>
>> The
>> problem is that from a semantic point of view, this function will
>> construct a smart pointer with a type, which is deduced from the
>> function's argument. The argument's value is only taken if it is not
>> expired, else the default value will be taken. get_shared_ptr doesn't
>> express this to me and I can hardly imagine that any identifier will do.
>
>>From semantic point of view, it's more like "This function will obtain a
> shared_ptr to the object identified by the weak_ptr argument. If there is no
> such object, an empty shared_ptr is returned."
>
> To me, get_shared_ptr seems to express this a bit better than make_shared.
> But I might be wrong.

If it were equivalent to construction, you could just do
   
   static_cast<shared_ptr<T> >(weak)

right?  I realize this doesn't deduce T.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution