Boost logo

Boost :

Subject: Re: [boost] [smart ptr] Any interest in copy-on-write pointer for C++11?
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2013-02-11 12:22:29

On Sun, Feb 10, 2013 at 2:27 AM, Pyry Jahkola <pyry.jahkola_at_[hidden]> wrote:

> On 2013-02-09 18:47:59 +0000, Andreas Pfaffenbichler said:
> a heavy argument for a 'COW' pattern is made here:
>> based-polymorphism<>
>> ( 'copy_on_write' class template included).
> I was going to reply about the same, but here's the whole class with
> documentation:
> 1copy__on__write.html<>
> maybe it could be interesting to compare your 'cow_ptr' to this
>> 'copy_on_write'.
> The biggest difference and, in my opinion, the most important advantage in
> favour of adobe::copy_on_write is that the copying is explicit; given a
> copy_on_write<T> x;
> you can only use
> x->const_member(); // no refcount overhead even if x is non-const
> to access const members of T. Whenever you need to modify the instance,
> you'll need to explicitly tell copy_on_write about it by calling write():
> T & r = x.write(); // write() performs the copy if needed
> r.mutating_member();
> or, matching the use case of cow::cow_ptr<T>::apply:
> f(x.write());
> This interface maps very nicely to dealing with value types: as long as
> you're treating everything as a value (i.e. read-only), there aren't any
> hidden costs of making a copy either. And as soon as you need to make
> changes to the data, the overhead of the internal copy will be visible in
> the code responsible of the mutations as well. I guess that's enough to
> clear most concerns about the thread-safety issues too.

+1 for explicit copy-on-write. At that point, you're basically just dealing
with something close to an augmented shared_ptr< T const >.

- Jeff

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