-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi! I'm a long-time user (and admirer) of the Boost libraries, and I've just uploaded a new one to the Boost Vault for consideration: the Extended Integer (XInt) library, a unlimited-precision integer library that I've been working on for the last few months. I'd like to request a preliminary review of it, please.
Well - BigInts have become like London Buses - you wait for ages and then six of them come along ;-)
Your Xint looks interesting, Boost styled (if not Boost-style tests), and Boost licence. Docs (though not Doxygen/Quickbook) and no examples. But these are trivial issues.
I can adapt the test suite, if someone could point me toward some description of how. I'm not sold on Doxygen as a good way to handle documentation, mostly because I've never seen any really good docs written in it. I did put an example in, in the documentation -- the Fibonacci example. There are a couple others in there too, like the one showing how the exception-blocking works. If it would help to have them as separate files too, that wouldn't be much of a problem.
I've not been following the WG21 discussions of Bigger Integers - perhaps you can summarise their response to N1744 (was is "we are too busy dealing with C++0X?").
Unfortunately I don't know anything about their response, or where I could find it. I didn't even know they'd addressed it until last week, when I saw mention of n1692 and n1744 in some older posts to this list. But I would have written that code even if they'd decided against it, because I had a need for it myself, for one of my own programs.
PS I note it doesn't (yet) specialise std::numeric_limits?
numeric_limits is something that is very highly desirable/essential for many applications (for example the Boost.Math package relies on this, and had to add it to be able to use the NTL package and GMP package).
I've put it on the to-do list. Though how useful it might be at this point is questionable... I doubt that very many packages test the is_bounded member, and most of the interesting non-floating-point-specific fields aren't specified when it's false.
NaN is essential IMO (if only to act as a 'missing value' marker (though I would favour a separate NaN for this purpose from std::numeric_limits<>::quiet_naN();
Sorry, I don't quite understand what you're suggesting I do in that last paragraph, if anything. The library has a NaN built in already, and numeric_limits<>::quiet_NaN is specified as being "meaningful for floating point types only." - -- 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/ iEYEARECAAYFAkus210ACgkQp9x9jeZ9/wRbigCgtQnj4a7N0rnUxbASwVYBSxmT 0Y8AoL0f8rBtYiQ3Z8IvE6761ma/vgzH =+b+O -----END PGP SIGNATURE-----