Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>See section 4.1.5 of the <a href="http://www.microsoft.com/download/en/details.aspx?id=7029" rel="nofollow noreferrer">C# 4.0 language specification</a>. Particularly, of interest: </p> <blockquote> <p>C# supports nine integral types: sbyte, byte, <strong>short</strong>, ushort, int, uint, long, ulong, and char. [omitted text]</p> <p>The integral-type unary and binary operators always operate with signed 32-bit precision, unsigned 32-bit precision, signed 64-bit precision, or unsigned 64-bit precision:</p> <ul> <li><p>[omitted bullet points]</p></li> <li><p>For the binary +, –, *, /, %, &amp;, ^, |, <strong>==</strong>, !=, >, &lt;, >=, and &lt;= operators, the operands are converted to type T, where T is the first of int, uint, long, and ulong that can fully represent all possible values of both operands. The operation is then performed using the precision of type T, and the type of the result is T (or bool for the relational operators). It is not permitted for one operand to be of type long and the other to be of type ulong with the binary operators.</p></li> </ul> </blockquote> <p>Operations using short are promoted to int, and those operations are lifted for their nullable counterparts. (This leads to sections 7.3.6.2 and 7.3.7)</p> <hr> <blockquote> <p>Ok, this is by Design, but still don't understand the why they do that, they have optimize the string adds too much, why left numbers alone and add more code for this simple comparing </p> </blockquote> <p>That is simply the way the language is designed, with a consideration for optimizations in modern architecture. Not specifically in this context, but consider the words of Eric Lippert as stated <a href="https://stackoverflow.com/questions/8671427/why-some-types-do-not-have-literal-modifiers">here</a></p> <blockquote> <p>Arithmetic is never done in shorts in C#. Arithmetic can be done in ints, uints, longs and ulongs, but arithmetic is never done in shorts. Shorts promote to int and the arithmetic is done in ints, because like I said before, the vast majority of arithmetic calculations fit into an int. The vast majority do not fit into a short. Short arithmetic is possibly slower on modern hardware which is optimized for ints, and short arithmetic does not take up any less space; it's going to be done in ints or longs on the chip. </p> </blockquote> <hr> <p>Your latest update:</p> <blockquote> <p>What I expect to compiler to do is to make a simple check with .HasValue if (cTestA.HasValue){} at least this is what I do on my code after I discover this conversion. So this is what I really do not understand why not do that simple think but add all this extra code. The compiler always try to optimize the code - why here avoid that simple .HasValue check. I am missing something here for sure...</p> </blockquote> <p>I will have to defer to a compiler expert to say why they elect to go for the conversion instead of the immediate HasValue check, except to say there could simply be an order of operations. The language specification says binary operator operands are promoted, and that's what they have done in the provided snippet. The language specification goes on to later say that checks with <code>x == null</code>, where x is a nullable value type, can be converted to <code>!x.HasValue</code>, and that is also what they have done. In the compiled code you have presented, the numeric promotion simply took precedent over the nullable behavior. </p> <p>As for the compiler <em>always</em> trying to optimize the code, again, an expert can clarify, but this is not the case. There are optimizations it can make, and others it defers to perhaps the jitter. There are optimizations that either the compiler or the jitter may or may not make depending upon whether it is a debug versus release build, with or without a debugger attached. And undoubtedly there are optimizations they could make that they simply elect not to, because the costs versus the benefits do not play out. </p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload