You lose the possibility to express your intent. There is no conceptual need in having shared ownership.
I agree with this. Libraries shouldn't dictate memory management strategies to their users. If you must accept only shared_future<> as preconditions, that's understandable. But it doesn't mean you need to return them, when they're not (yet) shared by anything.
This semantic distinction can have real, practical implications. When I see code using shared_ptr<>, it's a sign to me that the object is truly shared. This has implications on how I use it, so I need to take the time to understand with whom it's shared and how they access it. If it's not *really* shared, then it's misleading and potentially wastes users' time.
I don't know why you and the HPC crowd are conflating shared_ptr with shared ownership. It an atomic safe reference counting implementation which provides no guarantees to its pointee.
I find it personally unfortunate that C++ decided to call it shared_ptr because of the word "shared" in the name, because it really isn't what its name says.
I believe that a lot of thought went into this decision. And it's called shared_ptr exactly because of that it represents shared ownership. I think you're again confused about what's the rationale of the design and what's the consequence of it. Shared ownership is the rationale, being an 'atomic safe reference counting implementation which provides no guarantees to its pointee' is a consequence.
I might add that in AFIO I use the typedef handle_ptr. You don't think to think shared anything, just use afio::handle_ptr and stop worrying about shared_ptr. It's an implementation detail, and not important.
What kind of ownership with regards to the handle does the afio::handle_ptr give your user? Unique ownership or shared ownership? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu