Analysis on vb.net local static variable ———————— "Badboy"

After a long period of learning vb.net local static variables, so share with you, after reading this article you certainly have a lot of harvest, hope this article can teach you more things. Vb. NET can implement many functions that C # cannot do, such as when statements, optional parameters, local static variables, object instance access static methods, handles binding events, on error handling exceptions, Object direct late binding, and so on. VB and C # are the same genus. NET language, compiled is the same CIL, but why VB support a lot of interesting features. Let's explore vb.net local static variables.

Vb. NET local static variables

VB supports declaring local variables with the static keyword so that the value of the variable can be maintained at the end of the process:

Public Sub Test1 () Static I as Integer i + = 1 ' Implements a procedure call counter End Sub

We implemented a simple process counter. Each time the test is called, the value of the counter increases by 1. There are still a lot of situations where we want to keep the values of variables. The static of C # cannot be used inside the process. So to implement a process counter, we must declare a class-level variable. This is obviously not as good as VB. Because other procedures cannot be prevented from modifying counter variables. This is the case with the object encapsulation, it should be a method of local variables, and now I have to be forced to separate it out, is clearly a bad design. So how does VB generate local static variables? By returning the above code to the Assembly, we can clearly see that in the CIL generated by VB, I is not as a local variable, but as a field of the class:

. field Private specialname int32 $STATIC $test1$2001$i

In other words, I was renamed as a field of a class, but was crowned specialname. It is not possible to attempt to access $static$test1$2001$i in code because it is not a valid identifier. But in IL, the code that adds one to this variable is exactly the same as the normal class field, and is loaded by ldfld. I think this method is very clever, the static variable into a life cycle of the same class field, but also by the compiler to control access permissions, let it become a local variable. It also explains why VB uses two different keywords to declare static variables--static and GKFX.

because vb.net local static variable is the nature of the class field, so it and real The local variables are still different. For example, in multithreaded conditions, access to vb.net local static variables is the same as the Access field.