On Fri, Jan 29, 2016 at 11:24 AM, Rob Stewart
I understand that full well. The example that Emil presented can easily lead to having shared_ptrs that refer to release stack memory.
My original example was: { foo local; shared_ptr<foo> pl(&local,null_deleter()); .... do_something(p); .... assert(pl.unique()); } What if I change it to: int main() { foo local; shared_ptr<foo> pl(&local,null_deleter()); .... do_something(p); .... assert(pl.unique()); } Does it look less scary now? It seems that you guys look at this as "why would do_something take a shared_ptr if it can't keep a copy of it". Being able to retain a copy of the shared_ptr is one reason, yes. The other reason is that do_something needs to make sure that the object doesn't expire before it returns, which in this case it doesn't. Further, what if do_something is declared as: void do_something( weak_ptr<foo> const & ); Now it's not that it'll keep shared_ptr references after it returns, but it'll be creating and destroying shared_ptrs as needed, to make sure that the object doesn't expire while it's being used. Which, again, in this case it doesn't. Emil