Boost logo

Boost :

Subject: Re: [boost] [afio] Formal review of Boost.AFIO
From: Gruenke,Matt (mgruenke_at_[hidden])
Date: 2015-08-30 22:27:48


-----Original Message-----
From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Hartmut Kaiser
Sent: Friday, August 28, 2015 8:58
To: boost_at_[hidden]
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_ptr<afio::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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk