Re: [boost] [shared_ptr] Design question about make_shared

Subject: Re: [boost] [shared_ptr] Design question about make_shared
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2011-06-15 19:35:52

On Wed, Jun 15, 2011 at 3:35 AM, Stephan T. Lavavej
<stl_at_[hidden]> wrote:
> [STL]
>> Actually, make_shared<T>() needs access to shared_ptr's guts, at least if the
>> implementer takes advantage of the obvious and highly desirable optimization.
>> They are tightly coupled to begin with.
>
> [Emil Dotchevski]
>> However, the coupling between make_shared and shared_ptr is an
>> implementation detail.
>
> Right, that's what I was trying to say - internally, they are coupled, yet make_shared goes out of its way to be a free function.

I'm not sure if I read what you're saying correctly, but it seems to
me that the default for any design should be less, not more coupling.
If you make something a member, not only you're coupled, but also that
fact is part of the interface, and therefore not an implementation
detail.

I wouldn't say that make_shared goes out of its way to be a free
function -- it is a free function by default, so to speak. You need to
have an upside to making something a member function, something that
offsets the price you're paying in terms of coupling.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode