On Sun, 06 Mar 2011 22:17:55 -0800 "Jeffrey Lee Hellrung, Jr." <jhellrung@ucla.edu> wrote:
The only concrete complaint that people could give me about CoW was that code using it couldn't be made thread-safe [...]
Another concern with COW in general is iterator invalidation. Either your iterator gets "fatter" and slower (e.g., by being implemented as a pointer to the object + offset), or you expand the class of operations that invalidate iterators beyond just resizing operations to *any* modification operation (compared to a class which does not use COW). [...]
The iterator would have to hold a reference to the CoW object, to keep it from being changed or deallocated while the iterator is supposed to be valid, but other than that, the implementation that I see in my head wouldn't need to be any different, or be invalidated any more than without. Holding that reference ensures that nothing else will attempt to change the magnitude in any way. And if it's a non-const iterator, it would point to a unique instance anyway, ensured by whatever function provided the iterator.
Also, some of us have probably been "poisoned" by Herb Sutter:
http://www.gotw.ca/publications/optimizations.htm
If I'm reading the summary of his test harness correctly, fully 1/3 of the copies were never modified, which one might expect to give COW a huge advantage. Turns out, it only gave a 5 - 10% speed up over non-COW, and the thread-safe COW (all 3 implementations) netted a performance penalty.
A 5 - 10% speed improvement is nothing to sneeze at. And I'm not using thread-safe CoW, my design model doesn't need it.
Besides, even if turns out that COW gives some kind of benefit in some use cases, I believe it should be built on top of a non-COW base integer class. You can always add a COW layer on top of a base class, but you can't remove it.
A distinct possibility, which we can debate if testing proves that CoW is still beneficial. -- Chad Nelson Oak Circle Software, Inc. * * *