«

On Aug 28, 4:45 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> joe <jc1...@att.net> wrote:
> > Wouldn't it be better if unsigned integers saturated upon overflow
> > instead of wrapping?

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

--
James Kanze

James Kanze wrote:

> On Aug 28, 4:45 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
>> joe <jc1...@att.net> wrote:
>> > Wouldn't it be better if unsigned integers saturated upon overflow
>> > instead of wrapping?
>
>> Would make implenting a linear congruential generator harder.
>
> 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

James Kanze wrote:
> On Aug 27, 8:28 pm, "joe" <jc1...@att.net> wrote:
>> Wouldn't it be better if unsigned integers saturated upon
>> overflow instead of wrapping?
>
> 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?

>
> Why undefined behavior is not the case for unsigned integral
> types is somewhat of a mystery. I'm guessing that it is due to
> some pre-standard code counting on wrapping.

On 2010-08-27 15:59, joe wrote:
> Öö Tiib wrote:
>>
>> You are not forced to use arithmetic provided by language. You can
>> easily make your own numeric classes and their operations.
>
> 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.

--
Seungbeom Kim