Implicitly convert type "Int" to "short" causes and solutions

Take a look at the following Code : Copy code The Code is 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 correctly executed? What will happen? The result is: a compilation error occurs in this Code.
The correct code should be as follows:Copy codeThe Code is 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 ));

Why?
In fact, CLR only supports int, int64, native int, float, and double data types at the underlying layer. the underlying layer of sbyte, byte, short, ushort and CLR is not supported. The underlying types are represented by Int. number in the CLR stack. The minimum value is 4 bytes. If the value is smaller than 4 bytes, the number is extended by symbol or 0 is extended to 4-byte int type. in this way, the result of the four arithmetic operations is also int type, and the forced type conversion is required when the value is assigned again. analyze the compiled il code.

Why can the following code be compiled?

Copy code The Code is as follows: Short Sb;
SB = 2;
Sb + = 1;

In fact, the final value assignment in the compiled il Code also contains the type conversion operation.

Let's take a look at the more detailed explanation:Copy codeThe Code is as follows: short S = 0;
S = S + 1; // an error is reported. The right side is a complex expression. 1 is interpreted as an int.
S + = 1; // No error is reported. 1 is interpreted as short. See the following explanation.
S + = 32768; // an error is reported. Obviously, 32768 cannot be interpreted as short, but only Int.
S + = (S + 1); // an error is reported. The right side is a complex expression. 1 is interpreted as an int.

We can see from the above that a rule, that is,Implicit benign type conversion in complex expression computation, which is directly interpreted or converted to a 4-byte alignment CLS compatible type by default, such as int/long. The reason is simple: it saves the trouble, it guarantees performance.(There are not only considerations for running efficiency, but also considerations for code generation, so this consideration is one step in place). For example, 1 in S = S + 1 is interpreted as int, instead of short, this is reasonable.But if it is not a complex expression, but just a simple regular number, the compiler will not follow the "4-byte alignment CLS compatible type" in parse ", it automatically identifies the most suitable type based on other parts(This approach is also reasonable, because it is still in the parse stage, it is the top priority to quickly determine whether the type is compatible, performance is not performance, and non-alignment is a secondary issue, so, at this time, you do not need to explain the type of numeric constants in one step. Follow the fastest and most convenient principle ...), for example, S + = 1 and S + = 32768 are two examples. The former 1 is interpreted as short, so it is valid. The latter 32768 is forced to be interpreted as int, and the left and right types are incompatible, so an error occurs. Likewise, the above explanation applies to the example of S + = (S + 1): (S + 1) is a complex expression, not a simple numeric constant, so it is interpreted as (INT) S + (INT) 1 instead of (short) S + (short) 1.

note that the preceding explanations are mainly for the parse stage . In fact, in the code generation phase, the type may be further improved for performance and other purposes. For example, in the example of S + = 1, in the Il code generation phase, the (short) 1 identified in this parse stage is eventually upgraded to (INT) 1, which should be the 4-byte alignment of the Il parameter observed by Rick. In fact, to avoid confusion, I think it is sufficient for general users to understand the parser layer, because the type discrimination and compatibility check are no longer a key issue in the code generation phase , but of course, as long as the type is benign, no matter which stage can be done, or even, as long as the compiler has obtained the correct type information in the parse stage, the variable is converted to a non-benign type in the code generation stage, this is also a guaranteed design behavior. So far, I believe the explanation should be complete...