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

On 1/30/2016 2:20 AM, Rob Stewart wrote:

On January 29, 2016 3:35:54 PM EST, Emil Dotchevski wrote:

...

On Fri, Jan 29, 2016 at 1:40 AM, Rob Stewart wrote:

...

On January 29, 2016 2:48:56 AM EST, Emil Dotchevski < emildotchevski@gmail.com> 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.