Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2002-08-23 11:43:02

************* PLEASE STAY ON-TOPIC **************

If this conversation has strayed completely into the realm of "is the C++
language specified in the best way possible?", please take it to
comp.std.c++. Boost threads should have some relevance to C++ library


Dave Abrahams (with his moderator hat on)

           David Abrahams * Boost Consulting
dave_at_[hidden] *

----- Original Message -----
From: "David Bergman" <davidb_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, August 23, 2002 12:31 PM
Subject: RE: [boost] Re: (boost) Re: A pure C/C++ question

> Anthony,
> 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.
> /David
> -----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.
> Anthony
> _______________________________________________
> Unsubscribe & other changes:
> _______________________________________________
> Unsubscribe & other changes:

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