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

Subject: Re: [boost] [afio] Formal review of Boost.AFIO
From: Roland Bock (rbock_at_[hidden])
Date: 2015-08-31 11:15:36

On 2015-08-31 16:52, 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 did not read (much less understand) all of this part of the thread,
but shared ownership is exactly what shared_ptr is typically used for
(it it weren't shared, you would not need reference counting). That is
not limited to any particular crowd. Sean Parent even goes so far to
view shared_ptr variables like global variables.

So even if you do not use it this way, others will certainly treat it as
being shared...