Re: [boost] [afio] Formal review of Boost.AFIO

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
> [...]
> 20.9.2.2 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 
rigidities.

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.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/