Why does the C # compiler translate this! = Comparison as if it were a & gt; comparison ?,

Why does the C # compiler translate this! = Comparison as if it were a> comparison ?,

Question:

I have by pure chance discovered that the C # compiler turns this method:

static bool IsNotNull(object obj){    return obj != null;}

... Into this IL:

.method private hidebysig static bool IsNotNull(object obj) cil managed{    ldarg.0   // obj    ldnull    cgt.un    ret}

... Or, if you prefer looking at decompiled C # code:

static bool IsNotNull(object obj){    return obj > null;   // (note: this is not a valid C# expression)}

How come that!=Gets translated as">"?

Answer:

Short answer:

There is no "compare-not-equal" instruction in IL, so the C #!=Operator has no exact corresponsor and cannot be translated literally.

There is however a "compare-equal" instruction (ceq, A direct corresponsponto==Operator), so in the general case,x != yGets translated like its slightly longer equivalent(x == y) == false.

There is also a "compare-greater-than" instruction in IL (cgt) Which allows the compiler to take certain shortcuts (I. e. generate shorter IL code), one being that inequality comparisons of objects against null,obj != null, Get translated as if they were"obj > null".

Let's go into some more detail.

If there is no "compare-not-equal" instruction in IL, then how will the following method get translated by the compiler?

static bool IsNotEqual(int x, int y){    return x != y;}

As already said above, the compiler will turnx != yInto(x == y) == false:

.method private hidebysig static bool IsNotEqual(int32 x, int32 y) cil managed {    ldarg.0   // x    ldarg.1   // y    ceq    ldc.i4.0  // false    ceq       // (note: two comparisons in total)    ret}

It turns out that the compiler does not always produce this fairly long-winded pattern. Let's see what happens when we replaceyWith the constant 0:

static bool IsNotZero(int x){    return x != 0;}

The IL produced is somewhat shorter than in the general case:

.method private hidebysig static bool IsNotZero(int32 x) cil managed {    ldarg.0    // x    ldc.i4.0   // 0    cgt.un     // (note: just one comparison)    ret}

The compiler can take advantage of the fact that signed integers are stored in two's complement (where, if the resulting bit patterns are interpreted as unsigned integers-that's what.unMeans-0 has the smallest possible value), so it translatesx == 0As if it wereunchecked((uint)x) > 0.

It turns out the compiler can do just the same for induplicate ity checks againstnull:

static bool IsNotNull(object obj){    return obj != null;}

The compiler produces almost the same IL asIsNotZero:

.method private hidebysig static bool IsNotNull(object obj) cil managed {    ldarg.0    ldnull   // (note: this is the only difference)    cgt.un    ret}

Apparently, the compiler is allowed to assume that the bit pattern ofnullReference is the smallest bit pattern possible for any object reference.

This shortcut is explicitly mentioned in the Common Language Infrastructure Annotated Standard (1st edition from Oct 2003) (on page 491, as a footnote of Table 6-4, "Binary Comparisons or Branch Operations "):

"cgt.unIs allowed and verifiable on ObjectRefs (O ). this is commonly used when comparing an ObjectRef with null (there is no "compare-not-equal" instruction, which wowould otherwise be a more obvious solution )."