Subject: Re: [boost] New Boost.XInt Library, request preliminary review
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-03-26 12:05:53
-----BEGIN PGP SIGNED MESSAGE-----
>> 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
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
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."
Oak Circle Software, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk