From: Maarten Kronenburg (M.Kronenburg_at_[hidden])
Date: 2006-06-03 08:54:53
The assertion for unsigned_integer
is an interesting possibility.
In "C++ in a nutshell" I read:
"If the expression evaluates to 0,
assert prints a message to the standard
error file and calls abort."
Personally I would rather throw an
exception, so that the user can determine
what should happen if an unsigned_integer
I see it as equivalent to taking the square root
of a negative number.
Whether the unsigned_integer should
do an assertion or an exception is not part
of the interface. But this is also true for
taking a negative square root.
In the document I will present both possibilities,
assertion and exception, and give a few pros and cons.
"Carlo Wood" <carlo_at_[hidden]> wrote in message
> On Fri, Jun 02, 2006 at 11:53:18PM +0200, Maarten Kronenburg wrote:
> > The base type unsigned int is a fact.
> Historically grown out of the need of that extra bit,
> when cpu's didn't have 32 bits yet. If all you have
> is 8 bits, then it makes a big difference whether
> you can assign -127...128, or 0...255.
> > The modular_integer is a mathematical fact,
> > and the base type unsigned int is modular.
> Only because it's the natural way an overflow occurs.
> I don't think it's relevant that an (unsigned)
> integer is modulo 2^32 -- anyone USING that fact
> is doing something wrong imho (I wouldn't like to
> hire them!)
> > And users that want an integer that
> > is of infinite precision but they want to know
> > for sure will never become negative,
> That is a very weird demand. Are those users not sure
> what they are coding? "Oh, I don't have an idea what
> I'm doing, but instead of using an assert, I'll
> "recover" from possible bugs by enforcing this
> variable to become 4294967295 instead of -1..."
> (as if that won't crash the program).
> Sorry, but it makes no sense whatsoever to use
> unsigned integers with as reason that (only?!)
> then you are sure that they won't be negative.
> A bug is a bug: if a variable shouldn't become
> negative, then it won't. If you don't feel secure
> about it, add an assert.
> If the fact that an unsigned can't become negative
> is used in a _legit_ way then that can only mean one
> thing: they REALLY needed modular arithmetics. In the
> case of this precision library, that would be
> a modular_integer. Thus, if anyone would need
> an infinite precision unsigned integer, then they
> are doing something seriously wrong. Instead they
> should use an infinite precision integer and add
> an assertion to make sure it never becomes negative.
> I see no reason to replace the "bug catcher" (the
> assertion) with a special type, that throws an
> Carlo Wood <carlo_at_[hidden]>
> Unsubscribe & other changes: