"Peter Dimov" <[EMAIL PROTECTED]> writes:
> From: "Daniel Frey" <[EMAIL PROTECTED]>
>> 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
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
