Subject: Re: [boost] New Boost.XInt Library, request preliminary review
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-03-30 09:52:21
-----BEGIN PGP SIGNED MESSAGE-----
On 03/30/2010 07:13 AM, Stewart, Robert wrote:
>> I have to disagree, only because one of the main reasons people
>> want to use a large-integer library is for cryptography, and those
>> two functions *are* fundamental to that.
> "One of the main reasons," not "the only" reason. Hence,
> cryptography functionality, which surely is more than those two
> functions, should be in a separate library.
I'm sure it should. But those two functions should not.
>>> What did you find about Boost.Optional that was difficult for
>>> users to understand?
>> That it acts like a pointer but isn't one. Less experienced developers
>> often find even pointer syntax hard to master, and unfortunately, they
>> are the majority of programmers. I was trying to make it as easy as
>> possible for anyone, no matter what their level of experience, to use.
> This is being proposed as a Boost library. We can assume enough
> knowledge to use Boost.Optional, which isn't great.
Knowledge and patience are two things that I've learned never to assume
that a would-be programmer has.
>>> The interface to invmod and random_prime should be built around the
>>> interface of xint::integer, not the other way around.
>> Sorry, not good enough. They're an important part of the
>> interface, and their requirements affect it too.
> That's not a sufficient reason for their inclusion in a big integer
> library. Rather, the big integer library needs to be designed well
> to support those functions and many others.
invmod is a basic modular math function. random_prime is a basic
requirement for the most common reason people would want the library.
They belong there, and they stay.
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