-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Hartmut Kaiser Sent: Friday, August 28, 2015 8:58 To: boost@lists.boost.org Subject: Re: [boost] [afio] Formal review of Boost.AFIO
I think Niall's point is that it's harder for the wrapper to know whether it's going to be called a single time or multiple times for a given precondition future, so it's safest if that is accepted only as a shared_future.
It's more that when shared_future can only EVER refer to a shared_ptrafio::handle all of which is thread safe, I see little risk to defaulting to shared_future. What does one lose?
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. 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. Please don't overuse shared objects, simply because it seems safer. It can actually create *more* work for users of your library. Matt ________________________________ This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.