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
> >> 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
> 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.
> 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
> 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
> 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).
(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