Boost logo

Boost :

Subject: Re: [boost] [afio] Formal review of Boost.AFIO
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-08-31 10:52:11

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

> 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.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at