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
>> 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
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.
Reverge Studios, Inc.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk