On 3/6/2011 4:25 PM, Chad Nelson wrote: [...]
The only concrete complaint that people could give me about CoW was that code using it couldn't be made thread-safe, which is true. So I made a way to instruct the library to force all integer objects to have unique storage before they're returned to user code, and made it the default to prevent unpleasant client-code surprises. The internal code is single-threaded, and completely under my control in any case if I find it useful to make it multithreaded someday, so that answered the thread-safety complaint.
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). I don't know if this will be significant concern if (or once) xint::integer_t gets some kind of proxy objects into its internals (e.g., iterators), but...all things being equal, I prefer "slim" iterators and fewer iterator invalidation operations. 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. 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. - Jeff