-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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.
Yes to everything except for the "thread safe operations with and without COW semantics." The only way to provide fully thread-safe operation with copy-on-write enabled is by putting locking functions in the xint::integer class itself. I experimented with that, but in the end I decided that it just wasn't that class's place to do that sort of thing. As such, copy-on-write is only used when the library is compiled in single-thread mode.
Care to disclose the numbers?
In single-thread mode, running my test suite presently takes an average of 1.30 seconds. Still in single-thread mode, but with copy-on-write disabled, it's 2.42 seconds. (For the sake of completeness, full thread-safe mode also takes 2.42 seconds. The main difference is a mutex protecting the random number generator as well.)
I guess that you have read the COW string article (http://www.gotw.ca/gotw/045.htm) by Herb Sutter, and his conclusions.
Of course.
Optimizations on other parts should perhaps have been made before converting to COW semantics.
There were, a large number of them. They were insufficient.
Using COW semantics could also complicate the complexity requirements for most functions, as they may be "amortized O(something)" instead of just "O(something)".
Wouldn't you rather have "amortized O(something)" than just "O(something)", when the first O is about half the value of the second? ;-)
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.
I actually implemented it that way first. But after long consideration, I decided that a signaling NaN was better. With the non-signaling one, you could go through hours of calculations, only to find that NaN returned at the beginning of them rendered all that work useless.
Don't take these comments the wrong way, I'm very glad to see development of an arbitrary precision integer boost licensed library.
And I appreciate your comments, and your politeness in delivering them. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuuqTYACgkQp9x9jeZ9/wR4QQCglIIunbj56RuifAw6n8w6DkFi FHwAn34554rZI70/kMaLOdCrRV/va9Ce =bCzG -----END PGP SIGNATURE-----