On January 30, 2016 4:12:29 PM EST, Noah
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:
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)