F
Fred Ma
Hello,
I've been trying to clear up a confusion about
integer promotions during expression evaluation.
I've checked the C FAQ and C++ FAQ (they are
different languages, but I was hoping one would
clear up the confusion), as well as googling
groups and the web.
The confusion is that for a binary operator,
where both operands are of integral type.
If either operand is unsigned long, the other
operand is converted to unsigned long. The
confusing thing is that this has a higher
priority than checking for longs. Similarly,
unsigned ints are checked for before ints.
So it is likely that an int is converted to
an unsigned int, or a long is converted to an
unsigned long. I'm getting this from Schildt's
"The Complete Reference C++", 3rd ed.. I
realize his book is not exactly lauded here, but
I also checked an old draft of the c++ standard:
http://www.csci.csusb.edu/dick/c++std/cd2/conv.html,
and it says something similar (but not the same).
In item 1 of section 4.5, they also say that if
something can't fit into an int, it is interpretted
as an unsigned int.
Why is it OK to reinterpret a signed integral type as
its unsigned counterpart? If it's a negative number,
then all of a sudden, the reinterpretation yields a
large positive number. I'm assuming that the signed
number is modelled as a 2's complement number, even
though it may be implemented differently in hardware.
Likewise, the unsigned is modelled as a straight binary
coded decimal (BCD). Does the sign bit of the 2's
complement number becomes the MSB of the unsigned
number, with all other bits remaining unchanged?
I've TA'd digital electronics before, so I know that
the mechanics of adding a 2'c complement negative
number is the same as adding the BCD interpretation of
those same bits (as was pointed out in one of my google
groups searches). It seems (to me, and perhaps
wrongly) that the rule of converting signed integral
types to their unsigned counterparts is due to lack of
a better way to handle it. Perhaps the reasoning was
that the resulting bits would still be accurate if one
operand was negative while the other was positive.
I was wondering if anyone could confirm or correct my
understanding of this, and maybe offer some insight as
to why this order of promotion is desirable?
Fred
P.S. An interesting thing is that Schildt points out an
exception. If one operand is a long while the other is
an unsigned int whose value can't fit into a long (e.g.
on a platform where both had the same number of bits),
then both operands convert to unsigned longs. Again, the
conversion from a signed integrap type to an unsigned
counterpart.
I've been trying to clear up a confusion about
integer promotions during expression evaluation.
I've checked the C FAQ and C++ FAQ (they are
different languages, but I was hoping one would
clear up the confusion), as well as googling
groups and the web.
The confusion is that for a binary operator,
where both operands are of integral type.
If either operand is unsigned long, the other
operand is converted to unsigned long. The
confusing thing is that this has a higher
priority than checking for longs. Similarly,
unsigned ints are checked for before ints.
So it is likely that an int is converted to
an unsigned int, or a long is converted to an
unsigned long. I'm getting this from Schildt's
"The Complete Reference C++", 3rd ed.. I
realize his book is not exactly lauded here, but
I also checked an old draft of the c++ standard:
http://www.csci.csusb.edu/dick/c++std/cd2/conv.html,
and it says something similar (but not the same).
In item 1 of section 4.5, they also say that if
something can't fit into an int, it is interpretted
as an unsigned int.
Why is it OK to reinterpret a signed integral type as
its unsigned counterpart? If it's a negative number,
then all of a sudden, the reinterpretation yields a
large positive number. I'm assuming that the signed
number is modelled as a 2's complement number, even
though it may be implemented differently in hardware.
Likewise, the unsigned is modelled as a straight binary
coded decimal (BCD). Does the sign bit of the 2's
complement number becomes the MSB of the unsigned
number, with all other bits remaining unchanged?
I've TA'd digital electronics before, so I know that
the mechanics of adding a 2'c complement negative
number is the same as adding the BCD interpretation of
those same bits (as was pointed out in one of my google
groups searches). It seems (to me, and perhaps
wrongly) that the rule of converting signed integral
types to their unsigned counterparts is due to lack of
a better way to handle it. Perhaps the reasoning was
that the resulting bits would still be accurate if one
operand was negative while the other was positive.
I was wondering if anyone could confirm or correct my
understanding of this, and maybe offer some insight as
to why this order of promotion is desirable?
Fred
P.S. An interesting thing is that Schildt points out an
exception. If one operand is a long while the other is
an unsigned int whose value can't fit into a long (e.g.
on a platform where both had the same number of bits),
then both operands convert to unsigned longs. Again, the
conversion from a signed integrap type to an unsigned
counterpart.