There is however one catch to the unsigned_integer: the expression a-b-c Then look in [expr.add]: "The additive operators group from left-to-right". The integer binary operator- first clones the rhs, negates it, and then adds to it the lhs. This guarantees that when b or c are non-zero unsigned_integer, then ALWAYS an exception is thrown. BUT what about a-(b+c) Now (b+c) returns a temporary integer (not unsigned_integer), which is negated (NO exception) and a is added to it. So although the behaviour is compiler-independent because of the [expr.add] remark, the use of braces in expressions may change the behaviour of an unsigned_integer expression, that is while a-b-c may throw an exception, a-(b+c) may not. Regards, Maarten. "Maarten Kronenburg" <M.Kronenburg@inter.nl.net> wrote in message news:e5gvs8$jbm$1@sea.gmane.org...
If you don't mind I start a new thread here. The unsigned infinite precision integer is different from the base type unsigned int, which is actually a modular integer with modulus 2^n. Therefore two integer derived classes are needed: unsigned_integer and modular_integer. The unsigned_integer is an infinite precision integer which can only be positive or zero. The negate() of a non-zero unsigned_integer will always throw an exception. A subtraction which results in a negative value will do the same; therefore in my opinion there is no fundamental problem with this, as negation is subtraction from zero. The modular_integer has a static method static void set_modulus( const integer & ). When the modulus is not set, it is zero, in that case the modular_integer is identical to integer. Users that like an unsigned integer with a negate() that always works, will have to use a modular_integer and set its modulus to a positive value. In the document I will specify unsigned_integer and modular_integer, and thus implementations can provide them. Regards, Maarten.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost