Re: [boost] New Boost.XInt Library, request preliminary review

Subject: Re: [boost] New Boost.XInt Library, request preliminary review
From: Anders Dalvander (boost_at_[hidden])
Date: 2010-03-27 13:37:26

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