Unsigned integer wrapping on overflow

[James Kanze]

Would make implenting a linear congruential generator harder.

Only bad ones, for random numbers. But I do count on the
current semantics for hash code generation.

 

[Kai-Uwe Bux]

Only bad ones, for random numbers.

Actually, line 26 in Table 1 (Knuth: TAOCP, Vol 2, section 3.3.4) has
modulus 2^64 and is a pretty good RNG.

But I do count on the current semantics for hash code generation.

In implementing an unlimited integer type, wrapping also comes in handy.


Best

Kai-Uwe Bux

 

[joe]

It would be "better" (for some suitable definition of better) if
all types triggered some sort of hardware trap on overflow. (The
"undefined behavior" of signed integral types and floating point
types on overflow is designed to allow that.) Practically
speaking, however, this would result in significantly slower
programs on most platforms (or would require significantly more
intelligent compilers to get close to current performance).

So apparently not "better" then, but bad! So, do you think that having a
few saturating integers in the standard in ADDITION to the current ones
would be a good idea?

 

[Seungbeom Kim]

Like MS's SafeInt, I know. But if it was built-in to the low level, there
wouldn't be a need for those kinds of things. If people are doing it in
programmer-land, then surely the compiler could do it more efficiently?
And it doesn't have to be one way or the other, a new set of safe
primitive integers could be added for those who want to use them.

Maybe in C, where they prefer to add things (such as _Complex) directly
to the core language, provided there is a sufficient demand, of course.
However, C++ prefers to focus on providing facilities upon which people
can build things they want; e.g. classes and templates instead of _Complex.