On Sun, Jan 20, 2002 at 12:39:13PM -0800, Max Bian wrote:
> Are you saying that "2" being shifted is by-default (C spec) 16 bit
> (int type), not UInt32?
Are you saying that you were expecting it to be something else? :-)
C-like languages use a very simple rule to determine the types of the
various subexpressions within an expression. Unfortunately, not many
people here seem to know it.
Only what is *inside* a subexpression affects its type.
Something on the outside enclosing that subexpression might
want it to have some particular type, but that is irrelevant.
Here is one case:
UInt32 c;
UInt16 a, b;
[...]
c = a * b;
The subexpressions from the inside out are "a", "b", "a * b", and
"c = (stuff)". The types are calculated as follows:
"a" has type UInt16
"b" has type UInt16
the parameters of "*" are of type UInt16, therefore I must be a
16 bit multiply, and hence "a * b" has type UInt16
the left parameter of "=" is of type UInt32, while the right one
is UInt16, so I have to convert the RHS from UInt16 to UInt32
before I can do the assignment
(I'm oversummarising a little here; really it thinks in terms of
"unsigned int" etc rather than UInt16.)
This seems to surprise people more when the example is
UInt32 c = 1000 * 1000;
but the reasoning is exactly the same, and the multiplication is done in
16 bits. (Because "int" on m68k Palm OS is 16 bits.)
Jonathan's case, which I believe he's been struggling with for almost
two weeks now, is similar:
UInt32 c = 2 << 18;
"2" is an int, as is "18". The fact that the result of the 16 bit shift
operation is being assigned to an unsigned long is irrelevant.
"2" is an int, but "2L" is something else, as is "2UL".
The rule above is why overloaded functions in C++ must differ in their
parameters, not merely in their return types: return types look
outward, not inward, and it's inward where the overloading gets
resolved. ISTR that Stroustrup talks about this in his "Design and
Evolution of C++" book.
John "dropping too many hints that people could find in a BOOK!"
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/