Re: [boost] [smart_ptr] Interest in the missing smart pointer (that can target the stack)

Subject: Re: [boost] [smart_ptr] Interest in the missing smart pointer (that can target the stack)
From: Noah (duneroadrunner_at_[hidden])
Date: 2016-01-30 16:12:29

On 1/30/2016 2:20 AM, Rob Stewart wrote:
> On January 29, 2016 3:35:54 PM EST, Emil Dotchevski <emildotchevski_at_[hidden]> wrote:
>> On Fri, Jan 29, 2016 at 1:40 AM, Rob Stewart <rob.stewart_at_[hidden]>
>> wrote:
>>> On January 29, 2016 2:48:56 AM EST, Emil Dotchevski <
>>> emildotchevski_at_[hidden]> wrote:
>>
>>> If do_something() saves a copy of the shared pointer in a container,
>> for
>>> example, later references will refer to a non-existent object.
>> There's
>>> nothing you can do about it short of using assertions or another
>> runtime
>>> check with a call to std::terminate() or similar. That's hardly
>> ideal.
>>
>> That's hardly a problem if it never happens. :)
>
> True enough.

Wow, shared_ptr really is quite an impressive little data type. But are 
you guys suggesting that it's already an adequate "smart pointer to 
stack objects" solution? I dunno, I think the "someone saving a copy of 
the share_ptr" could be a legitimate problem. For example, someone might 
write a function that takes a weak_ptr as a parameter and stores a copy 
of the obtained share_ptr assuming that it points to a heap object. Then 
someone else might do the "shared_ptr to stack object" thing and then 
use that function with the inappropriate weak_ptr. Right? I mean I guess 
technically it's already a problem, but if we endorse "smart pointer to 
stack objects" as an ordinary programming practice it might exacerbate 
what is currently a very obscure issue. But why would someone store the 
obtained shared_ptr rather than the weak_ptr? Well, they might think 
that accessing an object through a weak_ptr is more costly, and it seems 
they would be correct: 
http://duneroadrunner.github.io/SaferCPlusPlus/#simple-benchmarks

So I have a couple of questions about shared_ptr's implementation. Would 
doing the "shared_ptr to stack object" thing still involve a refcount 
object being allocated on the heap? In which case, you would lose a lot 
of the (potential) performance benefit of putting the object on the 
stack in the first place. Right?
And also, how does make_shared<> combine the target object and refcount 
object into a single allocation? My current implementation of 
registered_ptr does it by just deriving a new object that contains both 
the target object (as the (public) base class) and the "management" 
object. This method is nice and simple, but it requires that the target 
type be able to act as a base class.