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

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

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,
Thomas

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

>
> Niall
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>