RE: [boost] Re: A pure C/C++ question

From: David Bergman (davidb_at_[hidden])
Date: 2002-08-22 12:07:02

Remember that this case of extending passed the 2^n world is totally
different from the legal optimization of a compiler "remembering" that
integer division was used and keeping the remainder from that operation
for a subsequent "%"...

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Victor A. Wagner,
Jr.
Sent: Thursday, August 22, 2002 11:58 AM
To: boost_at_[hidden]
Subject: Re: [boost] Re: A pure C/C++ question

At Thursday 2002/08/22 01:23, you wrote:
>Maxim Shemanarev writes:
>  > > If the committee is seriously considering ways to handle stuff, 
>how
> about
>  > > dealing with the two results returned by almost every integer
divide
>  > > instruction... quotient and remainder.
>  >
>  > Right. That's another thing. But in this case if you write x=a/b;
y=a%b; a
>  > compiler at least  *can try* to optimize this. In case of x*a/b it
cannot
>  > because it's not allowed to!
>
>Everyone is forgetting that integer overflow on signed types results in

>undefined behaviour.

This is an artifact of the language definition (a poor one, IMO).  When
_I_ 
learned multiplication (way back when I was 6 or 7) I noticed pretty
quick 
that if I multiplied a n digit number by an m digit number I _might_ get
an 
m+n digit number.  The first several computers I worked on always 
m+produced
a "two word" product from two "one word" operands.  I was somewhat 
disappointed to learn that the HLL's all seemed to ignore this "basic
fact" 
of mathematics.  <shrug> it's what we're stuck with, tho I still
consider 
it mostly intellectual laziness that led to it.  Especially with
strongly 
typed languages now.

>Since the only case in which you need the intermediate
>result to be larger than int is where (x*a) overflows, this expression 
>yields undefined behaviour in such cases. The upshot of this is that a 
>compiler is permitted (as an extension) to _define_ such behaviour, and

>ensure that x*a/b always yields the mathematically correct result if 
>the final result fits in an int. Obviously, if the final result doesn't

>fit in an int, you still have overflow (e.g. INT_MAX*INT_MAX/1), but 
>this actually allows implementations to define the result of a*b/c as 
>the mathematically correct answer where the final answer is in range.

allowing isn't the same as mandating

>Anthony
>
>_______________________________________________
>Unsubscribe & other changes: 
>http://lists.boost.org/mailman/listinfo.cgi/boost

Victor A. Wagner Jr.      http://rudbek.com
PGP RSA fingerprint = 4D20 EBF6 0101 B069 3817 8DBF C846 E47A PGP D-H
fingerprint = 98BC 65E3 1A19 43EC 3908 65B9 F755 E6F4 63BB 9D93 The five
most dangerous words in the English language:
               "There oughta be a law"

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost