Optimization of the compiler for private field Initialization

In today's review, you can see a similar piece of code written by yourself:

internal class TestClass{    private bool _inited = false;    private int _count = 0;}

In short, the private fields in a class are displayed with default values. Based on our past experience, this is not only an extra effort, but also a superfluous experience. Because "false" and "0" are the default values of "bool" and "int" respectively, that is, if values are not displayed, they will still be "false" and "0. in fact, this will take another step during execution, which is ugly code.

 

Is that true?

 

In fact, in some cases, the above Code is indeed executed once more, that is, after CLR assigns the default value to all fields, our logic will assign these fields to the default values, and the assignment process is completed in the constructor. However, this situation has a major premise: the debug mode.

 

Check the Il command of the testclass constructor compiled in debug mode. We can see that the command to assign the default value to the field is generated here, which partially confirms our conjecture.

 

Then compile the same code in the release mode and check whether the results are different.

 

We are pleased that the C # compiler has cleverly identified that this is a completely redundant piece of code and helped us optimize it, the constructor does not perform any operations on the private fields with default values. Under any circumstances, the released dll should be compiled by release, so the previous concerns are completely unnecessary. In addition, in this case, there is no performance loss. Assigning an initial value to a field explicitly makes it easier for readers to understand the author's purposes, I am not confused: "Is development forgetting the initial value or does he really want to do this? ".

 

After understanding this, let's take a further look:

internal class TestClass{    public TestClass()    {        _inited = false;        _count = 0;    }    private bool _inited;    private int _count;}

Such a piece of code is also compiled in the release mode. It is said that directly assigning values to fields is only a syntactic sugar assigned by the constructor. Will the above Code be optimized? Is the compiler so intelligent?

Unfortunately, it seems as amazing as we thought. Compared with the first il code diagram, we can find that the two constructors have different time points for private field initialization. The initialization point of direct value assignment is before calling the parent class constructor, the initialization point assigned to the constructor is after the constructor of the parent class is called. Here we can roughly guess the construction order of an instance, that is, there is a field first, then the parent class constructor is called, and then the self constructor is called. You can perform a simple verification using the following code:

internal class TestClass{    public TestClass()    {        _inited = false;        _count = 0;    }    private bool _inited = true;    private int _count = 1;}

We didn't assign the default value to the field, which forces the compiler to generate this il command. View its release compiled il commands:

 

The result proves our conjecture. The operation of assigning values to 1 in the red circle is the Il code that we assign values directly, which is executed before the object constructor is called. The 0 value assignment operation marked in the blue box is the Il code for displaying the value assignment in the constructor, after the object constructor is called.