Re: [boost] [xint] Boost.XInt formal review

Subject: Re: [boost] [xint] Boost.XInt formal review
From: Jeffrey Lee Hellrung, Jr. (jhellrung_at_[hidden])
Date: 2011-03-07 01:17:55

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