Chad Nelson wrote:
This disables the copy-on-write optimization that the library uses by default [...]
I'm not convinced that integers should be COW. What situations do you forsee where COW would be helpful but move semantics wouldn't suffice?
As described on the rationale page of the documentation, the primary reason I'm using copy-on-write is that move semantics aren't widely available yet. Portability is one of my primary goals, and while I've seen references to a move-semantics-emulator in Boost, I've also seen suggestions that it relies on the compiler to somehow recognize it. That doesn't sound fully portable to me.
No offense, but I'm not confident that COW semantics for the integer class is a wise design choice. I assume you have tested the performance with and without COW semantics, as well tested the performance for thread safe operations with and without COW semantics, before making that decision. Care to disclose the numbers? I guess that you have read the COW string article (http://www.gotw.ca/gotw/045.htm) by Herb Sutter, and his conclusions. Optimizations on other parts should perhaps have been made before converting to COW semantics. Using COW semantics could also complicate the complexity requirements for most functions, as they may be "amortized O(something)" instead of just "O(something)". Another concern I have is that NaN is "signaling" as most operations on a NaN integer will throw an exception. I think it would be more sound if operations on NaN integers would result in NaN integers, compare with float NaN. Don't take these comments the wrong way, I'm very glad to see development of an arbitrary precision integer boost licensed library. Best regards, Anders Dalvander