Boost logo

Boost :

From: Anthony Williams (anthwil_at_[hidden])
Date: 2002-08-28 08:42:03


David Bergman writes:
> I am just curious as to the type of the subexpression "a*b". Even though
> "all bets are off" regarding the actual values at each step, is the
> restriction imposed by the (32 bit) type int no longer applicable? In
> other words, is "a*b" no longer typed?

The type of the subexpression is still int, since types are a static property
of expressions at compile time. However, on overflow the results are
undefined, so there are no longer any restrictions on behaviour, and the
values are permitted to be outside the normally-representable range.

> Even though an implementation is free to do *whatever* it wants, before
> and after an undefined operation, w.r.t The C++ Standard, I really would
> like the types to stay intact, in representation and behavior, which in
> this case would defy the expression "a*b" denoting a 2*sizeof(int) byte
> long value...

What value would you give 32767*32767 on a 16-bit signed system, then? What
about 32767*32767/32767?

I would prefer that the latter is defined, even though the former isn't. You
may disagree. I would like the standard to say "the order of arithmetic
operations on signed integral types may be rearranged, or other mechanisms
used, to avoid overflow at intermediate steps, provided the final result is
the same for those cases that would not overflow if the expression was
evaluated as written", or something similar, but I'm not sure it would really
gain anything.
 
> Anyhow, we all know that there is nothing to be derived from our
> "bible", The International Standard, in these cases, which makes these
> discussions not only out-of-bounds w.r.t the Boost library, but also
> metaphysical if we believe C++ to be the reality.

:-)

This discussion is really getting quite pointless, especially since both MSVC
and g++ generate imul/cdq/idiv (or equivalent) on x86, rather than keeping the
extra precision at the intermediate step.

Anthony


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk