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
220.127.116.11 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.
> 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
>> 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.
> 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.: 09131/85-27018 Fax: 09131/85-27912 Email: thomas.heller_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk