[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c++

Arithmetic addition with strange results

Dizzy

9/10/2008 3:08:00 PM

Hello

I have noticed a strange behavior (tho for many of you this is to be
expected I'm sure :) ) when I have an expression that adds a long
value with an unsigned one (like in "10l + 10u").

On 32bit platforms (where unsigned can represent more than long) the
result is of unsigned long type while on 64bit platforms the result is
of long time.

Usually in my coding experience I've learned that when writing bool
expressions like "a - 10 < b" I should better write them "a < b + 10"
because somehow I thought this keeps the expressions to their original
types (I thought "b + 10" will have the type of "b") and then the case
of comparing signed to unsigned values depends if a and b were mixed
signed types. It seems that was false.

Can someone point me to the relevant standard section that
allows/requires that behavior described above?

Thank you!

--
Dizzy

2 Answers

Alf P. Steinbach

9/10/2008 3:17:00 PM

0

* dizzy:
> Hello
>
> I have noticed a strange behavior (tho for many of you this is to be
> expected I'm sure :) ) when I have an expression that adds a long
> value with an unsigned one (like in "10l + 10u").
>
> On 32bit platforms (where unsigned can represent more than long) the
> result is of unsigned long type while on 64bit platforms the result is
> of long time.
>
> Usually in my coding experience I've learned that when writing bool
> expressions like "a - 10 < b" I should better write them "a < b + 10"
> because somehow I thought this keeps the expressions to their original
> types (I thought "b + 10" will have the type of "b") and then the case
> of comparing signed to unsigned values depends if a and b were mixed
> signed types. It seems that was false.
>
> Can someone point me to the relevant standard section that
> allows/requires that behavior described above?

Just search (the standard) for "usual arithmetic conversions" and "promotion".

And yes, the type of an expression depends on the ranges of types with the
particular C++ compiler, and so does the type of a literal! :-)


Cheers & hth.,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

James Kanze

9/10/2008 4:33:00 PM

0

On Sep 10, 5:16 pm, "Alf P. Steinbach" <al...@start.no> wrote:
> * dizzy:
> > I have noticed a strange behavior (tho for many of you this
> > is to be expected I'm sure :) ) when I have an expression
> > that adds a long value with an unsigned one (like in "10l +
> > 10u").

> > On 32bit platforms (where unsigned can represent more than
> > long) the result is of unsigned long type while on 64bit
> > platforms the result is of long time.

> > Usually in my coding experience I've learned that when
> > writing bool expressions like "a - 10 < b" I should better
> > write them "a < b + 10" because somehow I thought this keeps
> > the expressions to their original types (I thought "b + 10"
> > will have the type of "b") and then the case of comparing
> > signed to unsigned values depends if a and b were mixed
> > signed types. It seems that was false.

> > Can someone point me to the relevant standard section that
> > allows/requires that behavior described above?

> Just search (the standard) for "usual arithmetic conversions"
> and "promotion".

> And yes, the type of an expression depends on the ranges of
> types with the particular C++ compiler, and so does the type
> of a literal! :-)

Right. In particular, don't mix signedness. Ever. If you're
stuck with a value which is signed, and another which isn't,
cast one of them to ensure that both have the same signedness.
(The exception is small non-negative values. You can safely use
integral literals like 0 and 1 with unsigned types, even though
they are formally signed. But that's about it.)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34