Boost logo

Boost :

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

On 31 Aug 2015 at 17:18, Thomas Heller wrote:

> > 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.
> From ISO/IEC 14882:2014:
> 20.9.2 Shared-ownership pointers
> [...]
> Class template shared_ptr
> The shared_ptr class template stores a pointer, usually obtained via
> new. shared_ptr implements semantics
> of shared ownership; the last remaining owner of the pointer is
> responsible for destroying the object, or
> otherwise releasing the resources associated with the stored pointer. A
> shared_ptr object is empty if it does
> not own a pointer.
> 'nuff said.

An excellent example of how theory based code design can introduce a
certain myopia in its adherants which leads to certain design

The ISO standard tries to describe behaviour guarantees rather than
implementation algorithms that must be used, and it does that above
for shared_ptr.

*IF* shared_ptr were implemented on ANY solution not using an atomic
reference count, I could see a strong rationale for considering
shared_ptr as the thingy which abstracts some of shared ownership.

But the reality is that on every implementation I'm aware of, it's an
atomically incremented and decremented reference count.

I *could* go roll my own reference count solution for AFIO. But
std::shared_ptr is well tested, well supported, I would assume well
optimised, and does everything I need.

So I grabbed the standard atomic reference count implementation which
comes in the STL and bent it to my needs, and I get on with life.

I would like to once again reiterate that AFIO exposes its use of
shared_ptr as afio::handle_ptr. You, the AFIO end user, need not
concern yourself with what kind of pointer handle_ptr is. You simply
need to accept that it behaves like any smart pointer. I might change
afio::handle_ptr to be something else at some future point, and your
code need not concern itself about that.

This witch hunt over my use of shared_ptr I think is done now. I've
proven its overhead is inconsequential in AFIO's use case. I think we
can accept this design decision is not important and move on now.


ned Productions Limited Consulting

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