|
Boost : |
Subject: Re: [boost] New Boost.XInt Library, request preliminary review
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-03-30 18:12:09
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/30/2010 05:47 PM, Scott McMurray wrote:
>> Well, it's not called an "infinite range integer," after all. :-)
>> Just an unlimited one, because the library does not place any
>> limits on it. Only available memory, and the time needed to operate
>> on something that large, do.
>
> The library *does* impose a limit: It has to allocate space, so
> there's necessarily the limit implied by the size of the type passed
> to the allocator to request the space.
That's size_t, which is defined as an unsigned 32-bit integer on my
32-bit machines. Unless I've got my sums wrong, such an integer can hold
4GB, which not coincidentally, is the maximum amount of address space
that a program on a 32-bit machine can address. Ditto 64-bit size_t on a
64-bit system. So it's not really a limit.
> Take, for instance:
>
> pow(xint(-1u), xint(-1u))
>
> That should probably throw an overflow error from checking ahead of
> time that the amount of memory requested is infeasible in the same
> way as std::vector<int>(-1) will throw a std::length_error.
Probably so, but I don't think checking it before starting calculations
is feasible. For one thing, what would you compare it to, to see whether
it's too big? There's no standard C++ call (so far as I know) to get the
amount of free memory on the system. And if there were, the system
wouldn't necessarily be able to provide all of it.
> (Yes, I agree that it's not a limit anyone should ever be hitting in
> useful programs, but...)
But bugs happen, and people might specify it by accident, even if
they're intending only to use numbers that would easily fit into memory.
(Yeah, I've made that kind of mistake before myself.) ;-)
- --
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/
iEYEARECAAYFAkuydzkACgkQp9x9jeZ9/wQO3QCg2xN+zwGTBU7nVWXjhPOnXc1j
J7IAoKSSuYy0kFE5iWSxXumOCquqOyBF
=SFfV
-----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