Boost logo

Boost :

Subject: Re: [boost] [afio] Formal review of Boost.AFIO
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2015-08-31 15:42:53

On 08/31/2015 07:08 PM, Niall Douglas wrote:
> 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
> 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.

Yes, it describes the behavior. What you describe is totally beyond me,
please provide me with your goggles to cure me and the rest of the (C++)
world from our myopia.

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

I have no clue what that even means. Must be because I am German.

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

Ok, please provide an example other than sharing ownership to a
pointer/resource that requires atomic reference counting?

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

So it's a witch hunt now? My post was merely to inform you about what
others think about what semantics a shared_ptr implies. You don't have
to like it, just be aware that without a common ground of definitions,
there can be no profounded technical discussion. Call it a witch hunt if
you like...

 From your "ivory tower"-ly yours,

P.S.: I am casting a spell with over 9000!

> Niall
> _______________________________________________
> Unsubscribe & other changes:

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