Boost logo

Boost :

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


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