Re: [boost] (RFC) make_shared name change

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

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

> From: "Daniel Frey" <daniel.frey_at_[hidden]>
>> Peter Dimov wrote:
>> >
>> > 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.
>>
>> I've always seen it another way: make_* names are convenience functions
>> which use argument deduction to save me some typing (there are even
>> cases where I can't write the type down easily).
>
> Good summary, I agree.
>
>> I don't expect them to
>> match on constructors directly. Is there any reference about which is
>> the "right" meaning of make_*? What do others think?
>
> FWIW, I've seen people incorrectly deduce from the name that make_shared has
> the same semantics as the constructor.
>
>> > >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."
>>
>> Which omits the type deduction part. It seems that this is why I have
>> problems moving away from make_*...
>
> That's true. The intent of make_shared/get_shared_ptr has nothing to do with
> argument deduction, and it doesn't save any typing:
>
> if(shared_ptr<X> px = make_shared(wp))
> {
> // ...
> }
>
> You still need to spell "shared_ptr<X>" in its entirety. 

I don't think so:

    some_function(make_shared(wp));

> The idiomatic use doesn't match the name.

But my example may not be idiomatic.

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