Boost logo

Boost :

Subject: Re: [boost] [smart_ptr] Interest in the missing smart pointer (that can target the stack)
From: Rob Stewart (rob.stewart_at_[hidden])
Date: 2016-01-30 22:01:42


On January 30, 2016 4:12:29 PM EST, Noah <duneroadrunner_at_[hidden]> wrote:
> 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:
>
> 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?

We're suggesting that you can use it for that case when you know enough about the code using the shared_ptr to be confident that a reference won't be saved to long. We're also suggesting that doing so permits using shared_ptr our weak_ptr as the parameter type of a function that doesn't save references to the memory.

> I dunno, I think the "someone saving a copy of
> the share_ptr" could be a legitimate problem.

It certainly is a problem, but there's already a lot of rope with which to hang oneself in C++. It's a tool that must be wielded with care.

> 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?

Yes to both questions.

> And also, how does make_shared<> combine the target object and
> refcount
> object into a single allocation?

It uses perfect forwarding, or an emulation of it, to construct the object in the single memory block along with the control block (which includes the reference count).

___
Rob

(Sent from my portable computation engine)


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk