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 11:18:15

On 08/31/2015 04:52 PM, Niall Douglas wrote:
> On 31 Aug 2015 at 2:27, Gruenke,Matt wrote:
> 
>>> You lose the possibility to express your intent. There is no conceptual
>>> 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.

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

> 
> 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 
> important.
> 
>> Another reason why it might be necessary to understand the ownership
>> structure of shared objects is a consequence of the fact that ref
>> counting != garbage collection.  Since it's incumbent on the user to
>> avoid circular references, this is also a cost, in development time. 
> 
> I think you are making up speculative problems here. This has never 
> been an issue in anything I've written using AFIO to date, and I 
> would doubt it ever will.
> 
> Niall
> 
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> 

-- 
Thomas Heller
Friedrich-Alexander-Universität Erlangen-Nürnberg
Department Informatik - Lehrstuhl Rechnerarchitektur
Martensstr. 3
91058 Erlangen
Tel.: [phone]
Fax:  [phone]
Email: thomas.heller_at_[hidden]