Subject: Re: [boost] [afio] Formal review of Boost.AFIO
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2015-08-31 11:50:19
> > > You lose the possibility to express your intent. There is no
> > > 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
What kind of ownership with regards to the handle does the afio::handle_ptr
give your user? Unique ownership or shared ownership?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk