• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
  • Mikalai Zaikin

arithmetic promotion and bit shifting

Ranch Hand
Posts: 133
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

As we know, because b is promoted to int before shifting, the above code will cause compiling error.
However the following code compiles neatly.

Please note unary cast operator() has higher precedence than the signed right shift operator>>. So I thought the above two codes are exactly the same. To support my argument, the same code does not compile with unsigned rigth shift >>>:

Can someone explain the inconsistancy?

[This message has been edited by Tom Tang (edited January 21, 2001).]
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Your second program compiles because you are supplying a compile-time literal value which fits in a byte, so no cast is needed. This is demonstrated by the following line which compiles ie. your line of code without the cast.

The important point is that -64>>4 can be calculated at compile time and returns -4 which is acceptable as a byte.
Your third program does not compile because the unsigned right-shift of -64 produces a very large value, far too big for a byte. So, even though the result of the shift is available at compile time, the compiler can see that you are trying to squeeze a large value into a byte, so it objects. You can make the code compile by bracketing the shift operation and applying the cast to it, but the result is truncated.

I think this explains what your are observing. There is no inconsistency.

    Bookmark Topic Watch Topic
  • New Topic