Boost logo

Boost :

From: David Bergman (davidb_at_[hidden])
Date: 2002-08-23 11:31:20


What is the type of the sub expression "a*b"? If it is an "int" it needs
to hold a specific number of bits, which is not to exceed the number of
bits held by "long".

What I am opposing is the 2^32 (or whatever the cardinality of "int" is
on the particular platform) out-of-band values.

Well, I thought C++ was a strongly typed language in the extended sense
of each (sub)expression confining to one type... If the "a*b/c" is
allowed to transcend those types in between the sub expression and the
full expression, then I know better.


-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Anthony Williams
Sent: Friday, August 23, 2002 4:30 AM
To: boost_at_[hidden]
Subject: RE: [boost] Re: (boost) Re: A pure C/C++ question

Greg Colvin writes:
> At 12:38 PM 8/22/2002, David Bergman wrote:
> >And, obviously, signed integer arithmetics cannot take place in a
modulo > >ring, since such a ring does not include negative numbers...
> > > >But, that is not a loop-hole for using double-precision in
interims, > >since the positive numbers of "int" (just to take an
integral example) > >have to be a subset of "unsigned int", so see, you
still cannot maneuver > >out of the modulo ring... > > > >I.e., it is
still invalid of an implementation to do the trick you > >described. >

> No, it is perfectly valid. If the product of two ints overflows all
> bets are off.

Which means, as I said before, that a compiler can define it in specific
circumstances --- i.e. they can say "a*b/c" is valid if it yields an
in-range result, even if a*b overflows. Many (x86) compilers will
provide a valid result in this case anyway, because its the fewest
instructions, and undefined behaviour on overflow means they're allowed.
If the result still doesn't fit, they'll generate a divide-by-zero
error, which is also allowed as undefined behaviour.


Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at