Look at the following code:
Copy Code code as follows:
SByte SBA, SBB,SBV;
SBA = 1;
SBB = 2;
SBV = SBA + SBB;
byte Ba, BB, BV;
ba = 1;
bb = 2;
BV = ba + bb;
Short SA, SB, SV;
SA = 1;
SB = 2;
SV = sa + sb;
ushort USA, USB, USV;
USA = 1;
USB = 2;
USV = USA + USB;
Do you think this code can be executed correctly? The result: This code will have a compile error.
The correct code should read as follows:
Copy Code code as follows:
SByte SBA, SBB,SBV;
SBA = 1;
SBB = 2;
SBV = (sbyte) (SBA + SBB);
byte Ba, BB, BV;
ba = 1;
bb = 2;
BV = (byte) (BA + bb);
Short SA, SB, SV;
SA = 1;
SB = 2;
SV = (short) (SA + SB);
ushort USA, USB, USV;
USA = 1;
USB = 2;
USV = (ushort) (USA + USB);
MessageBox.Show (String. Format ("{0},{1},{2},{3}", SBV, BV, SV, USV));
What's the reason?
In fact, the CLR supports only int,int64,native int, float, and double data types. Like the sbyte,byte,short,ushort above, the CLR is not supported at the bottom, where these types are expressed in int. The number that is pressed in the CLR's stack, with a minimum of 4 bytes, a symbol extension of less than 4 bytes, or a 0 extension to a 4-byte int, depending on its type. The result of this arithmetic is also int, and the last assignment requires coercion type conversion. The analysis of the compiled IL code is clear.
Why does the following code compile?
Copy Code code as follows:
Short SB;
sb=2;
SB = 1;
In fact, the final assignment in the compiled IL Code also includes a type conversion operation.
look at the more detailed explanations:
Copy Code code as follows:
Short s=0;
s = s + 1; Error, the right end is a complex expression, 1 is interpreted as an int
S+=1; No error, 1 is interpreted as short, please see the explanation below
s + + 32768; Error, obviously 32768 can not be interpreted into short, can only be interpreted as int
s+= (s+1); Error, the right end is a complex expression, 1 is interpreted as an int
From the above we can see a rule, that is,
implicit benign type conversions in complex expression calculations are implicitly interpreted or converted into 4-byte aligned CLS-compliant types, such as Int/long, for simple reasons: both saving trouble and ensuring performance(not only for operational efficiency considerations, but also for code generation considerations, so this consideration is one-step), for example, 1 of the s=s+1, which is interpreted as int rather than short, is reasonable.
but if it is not a complex expression and is just a simple constant number, the compiler will not follow the "4-byte aligned CLS-compliant type" when parse, which will be based on the other parts of the type that are most appropriate for the dynamic discrimination (This approach is also reasonable, because at this time is still in parse stage, quickly determine whether the type is compatible is the first priority, performance is not performance, right is the secondary problem, so, the type of the number of constant interpretation also need not one-step, follow the fastest most convenient principle can ... , such as S+=1 and s+=32768, two examples, the former 1 is interpreted as short, so legal, the latter 32768 will be forced to interpret as int, the left and right type incompatible, so error. In the same way, the above explanation applies to the s+= (s+1) Example: (s+1) is a complex expression, not a simple numeric constant, so it is interpreted as (int) s+ (int) 1 instead of (short) s+ (1), thus giving an error. &NBSP
Note that this explanation is primarily for the parse phase . In fact, in the code generation phase, the type may be further elevated for performance purposes, as in the case of s+=1, in fact, in the IL code generation phase, this parse phase identified (short) 1 was eventually promoted to (int) 1, this should be the IL parameter 4-byte alignment that Rick observed.
in fact, to avoid confusion, I think the general user understands that the parser level is sufficient, because the type of discriminant and compatibility check in the code generation phase is not a key issue , but of course, as long as the benign type of ascension, No matter which stage can be done, even, as long as in the parse phase compiler has obtained the correct type information, then, in the code generation phase of the variable for the conversion of the benign type, this is also a guaranteed design behavior. At this point, I believe the explanation should be complete ...
