Jeffrey Lee Hellrung, Jr. wrote:
It *can* be made thread-safe if you use atomic operations (as far as I know; someone correct me if this I'm wrong here). However, that likely introduces overhead even when you only need single threaded usage.
Well, it doesn't really matter whether it introduces overhead compared to unsafe CoW if we operate under the constraint that the library must be thread safe (which, quite frankly, it must be in this day and age). The competition there is only between CoW with atomic inc/decrements and deep copy. Move, by the way, eliminates an atomic increment and decrement in the same cases in which it would eliminate a deep copy. I probably should note that expression templates require CoW, as far as I can see; if you return an expression from a*b instead of computing the product, the expression needs to keep a and b alive. Having it store copies would defeat the purpose. Storing references wouldn't work well in generic code such as a forwarding function. Even something as simple as auto x = f() + y; would be a subtle bug. I wouldn't worry much about the branch in this context. :-) CoW aside, I do worry about the apparent overtemplatization of the library (possibly as a result of Boost feedback) and the calls that it isn't templatized enough. There are many potential users of an unlimited precision integer library who do not care in the slightest about implementation details and just need an integer class that provides the appropriate operations. For the people who do care, the library should provide free function templates that operate on a well-defined Integer concept which is "operationless" on its own and only stores bits (in chunks of some element_type perhaps). The supplied 'integer' class would be our best effort of implementing this concept in the manner we think is best for the users who want us to make this decision for them. The rest should be able to define their own integer classes and get the operations "for free".