On 31 Aug 2015 at 2:27, Gruenke,Matt wrote:
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 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.
Another reason why it might be necessary to understand the ownership structure of shared objects is a consequence of the fact that ref counting != garbage collection. Since it's incumbent on the user to avoid circular references, this is also a cost, in development time.
I think you are making up speculative problems here. This has never been an issue in anything I've written using AFIO to date, and I would doubt it ever will. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/