On 1/28/2016 8:09 PM, Emil Dotchevski wrote:
And it's way too easy to break that guarantee because it's not the semantics that shared_ptr was designed for.
{ foo local; shared_ptr<foo> pl(&local,null_deleter()); .... do_something(p); .... assert(pl.unique()); }
Yes, in the presence of exceptions one must also assert(pl.unique()) in a catch(...), and yes, compile-time errors are better than run-time errors, but I wouldn't sacrifice the availability of weak_ptr and the capacity of shared_ptr to act as THE single smart pointer framework in a program.
Why on earth would you ever do this? There is no shared ownership semantics here at all. I'm going to assume that is supposed to read do_something(pl); do_something can't retain ownership of the shared_ptr without the processor melting so why give it a shared_ptr at all?