-----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-----