Boost logo

Boost :

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:

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at