Languages such as Java and C specify implicit widening of integer types for numeric operators, especially arithmetic operators, to a minimum of 32 bits. What is the rationale behind doing this?
My impression is that it's based on the end-programmer's expectations - that is, 200 + 100
should yield 300
, and not overflow to 44
. Is there additional impetus behind this implicit type conversion?
This decision to widen only to 32 bits seems a bit arbitrary to me. Besides performance/memory concerns (some target instruction sets don't support 64-bit numbers, so more instructions are necessary), why not widen to 64 bits to minimize overflow as much as possible? If a language were designed which required 64-bit integer promotion for the operands of a numeric operation, would a sufficiently sophisticated optimizer be able to optimize down to 32-bits where sufficient (or, given that I have a pretty poor grasp on computability, is such an optimization impossible)?
TLDR: why are 200
and 100
in 200 + 100
widened to 32 bits? Why not 64 bits? Would a language be significantly inefficient if converted operands to 64 bits, especially if implemented with a "good" optimizer?
0xff000000 >> 4
becoming0xff00000
instead of0xfff00000
. $\endgroup$ – skeggse Jul 5 '15 at 1:50