On Sat, Jan 30, 2016 at 1:12 PM, Noah
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?
Some problems don't have a solution, you have to pick the right compromise. The use of shared_ptr has the advantage of enabling the use of weak_ptr and of interfaces that are expressed in terms of shared_ptr and don't care what deleter was used with each instance. The disadvantage is that it could lead to programmer errors, though the assert in my example should detect them.
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?
With some extra acrobatic moves you can use an allocator (once you have solid evidence from your profiler that this particular heap allocation creates performance problems, though I'd bet the lunch money that in practice that won't ever happen.)
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.
How it's done is unspecified :) but do note that shared_ptr goes beyond not requiring the target type to be able to act as a base class, it even works with void, e.g. this is valid C++: shared_ptr<void> p(new my_type); //When the last reference expires, ~my_type will be called. Emil