Re: [boost] Infinite precision integer draft

From: Carlo Wood (carlo_at_[hidden])
Date: 2006-06-02 19:51:15

On Fri, Jun 02, 2006 at 06:40:00PM -0400, Topher Cooper wrote:
> 1) Unsigned integer is not just an arbitrary restriction on range but 
> an important concept in its own right.  Its use clarifies intent.  In 
> my opinion, for example, it is a common, though minor, programming 
> error to use "int" rather than "unsigned int" when you intend to 
> express cardinality of something (e.g., the size of an array).  The 
> only real justification otherwise is to allow such practical "tricks" 
> as testing if a decreasing index is less than 0.

I disagree. Such 'intent' can, and should, be put in the name of the
variable. when it's a size, you can use the builtin type anyway.
We are talking about arbitrary precision unsigned integers; I see
no use for that. The only reason for it's existance is when you
actually (want to) rely on the fact that it will throw when it
becomes negative. I think the users should be protected from bad
usage like that.

> 3) Normal use of an unsigned integer type will never "try" to produce 
> a negative result -- its not a meaningful concept, so if you play by 
> the rules it doesn't happen.  You certainly would never try to negate 
> a cardinality (how often do you write code that says "If this string 
> contains 27 characters then I want another one containing -27 
> characters?).  Subtraction does have to be done with care, but in 
> most cases the issue of subtracting a larger from a smaller doesn't 
> come up.  Subtraction generally appears, sometimes subtly so, as a 
> computation of the size of the complement of a subset within a larger 
> set.  If you are dealing with where you would want to use unsigned 
> integers and you unwittingly do subtract a larger from a smaller 
> value -- if your program logic does not protect you from it -- than 
> you better have an exception.

I disagree once more -- if you unwittingly subtract a larger from a smaller
value then the program is bugged. There is no reason to add a special
type of this kind of bug, and not for other range checks (ie, what
if I don't want it to become larger than 1000000? Or when the variable
should be negative all the time and may not become positive? etc)

> 4) If the exceptions are exceptional than in most systems it is very 
> much more expensive to do an explicit test than to set up to handle 
> an exception.

In order to throw the exception when the value DOES become less
than zero, you will have to build the test into the library.
So, your "much more expensive to do an explicit test" will be forced
upon the users, even those who can code correctly so that their
variables indeed will never become negative anyway. The tests will
be 100%, useless, overhead, in the final program.

I'm not against extra tests all over the place, but that is
debugging code which should not be compiled into the production
version. An assertion is therefore what you want: that code is
not compiled, once the code is stable.

-- 
Carlo Wood <carlo_at_[hidden]>