C# to IL 6 Reference and Value Types(引用类型和值类型)

An interface is a reference type, in spite of the fact that it has no code at all. Thus, we
cannot instantiate an interface. We can use it as a construct for the creation of new types.
An interface defines a contract that is left to the class to implement.
An interface can have static fields. If an interface contains 10 abstract virtual functions,
then the class implementing from that interface has to supply the code for all 10 of them.
Thus, if a class does not provide all the function implementations, then we cannot use the
class. In such a scenario, a class derived from it must provide the implementation.
The interface keyword in C# is a class, which the documentation describes as a semantic
attribute.

We are not allowed to place any code in an interface. An interface consists only of the
function prototype, followed by a pair of curly braces {}

vijay1 is a function created in the interface yyy. As this is not permitted, the il assembler
has the domino effect as shown above

No variables either can be placed inside an interface. This rule is similar to that of C#.
Even though the documentation says that we can place static fields in an interface, when
we tried to do so, an error was generated.

If we create an object such as an interface using newobj, the assembler does not generate
any error, but the runtime throws an exception

The above program has only one function, a1 in the interface. This function has a pair of
curly braces {}, but as mentioned earlier, we are not allowed to place any code within them.
The class zzz has been derived from yyy, using the keyword implements. The assembler
does not check whether all code of the interface is implemented as it is done only at
runtime, and hence, an exception is generated. Thus, we can see that most IL errors occur
at run time, and not at compile time

To reiterate what we have said earlier, an interface in C# becomes a class directive in IL
with the interface modifier added to it. The two functions a1 and a2 become actual
functions in the class ddd, and are marked as virtual, newslot as well as abstract, i.e.
having no implementation

We cannot place any code, including a ret, in a method that is marked as abstract. This
modifier signifies that the code for the function will be provided from some other source.
Inspite of what the documentation says, a static constructor cannot be placed in an
interface.

For the purposes of inheritance, C# does not differentiate between an interface and a class.
There is, however, a subtle difference between them in a sense that, we can derive from
more than one interface, but not from more than one class.
In IL, there is a marked differentiation between an interface and a class. We extend from a

class and implement an interface. This is the same syntax that the Java programming
language uses.
When one compares C# with Java, their support for features such as these should be
highlighted

We created two locals that look like class yyy and interface ddd. Then, we created an object
that looks like yyy and initialized the variable V_0 to it.
The statement d =a is translated to: loading the value of V_0 on the stack, and using
instruction stloc.1 to initialize the variable V_1. Thereafter, calling the function a1 of the
interface ddd.
We loaded the variable value V_1 on the stack. Since it was called through the interface, we
used callvirt instead of call. If we had called it through the object of type yyy, then we
would have used call.
Thus, IL understands that a call through an interface object is to be treated in a special
manner. We can change the last occurrence of ldloc.1 to ldloc.0, since both have the same
values. A call to an interface is evaluated at run time, as the assembler does not convert it
into a class access. In the locals directive, the word class, and not interface, is placed in
front of ddd.
Thus, calling a function through an interface is equivalent to using callvirt since, there is
no code in the interface. A callvirt takes more time to execute than the plain call
instruction. However, callvirt introduces dynamism at runtime.

We have created a class yyy that is derived from two interfaces, ddd and eee, that have the
same function a1.
Since we want a separate implementation for each, we have to preface each occurrence of
a1 with the name of the interface, i.e. either ddd or eee, in the class yyy.
We have created the two objects that look like yyy and stored them in classes that look like
ddd and eee. Since the function is called from an interface pointer, we have to use callvirt
instead of call. In the IL code, the two interfaces are created as shown earlier.
In class yyy, we implement from ddd and eee, but since the two functions cannot have the
same name, we have to preface the name of the function with the name of the interface.

In the method, we have used a directive called .override. This directive clearly specifies as
to which function from a specified interface the function override. Calling of an interface is
a run time issue. The CLR does all the routine work.

The above program clears a large number of cobwebs. Let us start analysing this program
from the beginning.
We have a class interface ddd that has two functions a1 and a2. We then create a class
yyy, that implements from ddd and contains code for only one function a1.
This makes the class incomplete and hence, we tag it with the modifier abstract. However,
this modifier is optional. One more class xxx is created, that derives from yyy and
implements the second function a2. All goes well so far.
Then, using call, the function a2 of class xxx is called. However, when we call the same
function off the interface ddd using callvirt, the function is called off class yyy and not xxx.
This is so as the function in class xxx has nothing to do with the one in class yyy.
Compare this example with the override modifier example shown earlier. If we eliminate the
code of function a2 from the class yyy, we get the following error:

The function a2 is present in the class xxx, but it has been eliminated from the class yyy.
However, the function needs to be present in both the classes.
The same rules of nesting apply to interfaces also. Nothing stops an interface from
implementing another interfaces, using the keyword implements. Here, the word
implements may be misleading.
The keyword implies that the class that implements this interface must provide the code
for it.

An interface has five restrictions:
i. All methods must be either virtual or static.
ii. The virtual methods must be abstract and public.
iii. No instance fields are allowed.
iv. An interface is abstract and cannot be instantiated.
v. An interface cannot inherit from a class.
vi. Under no circumstances can an interface contain code.

A structure handles memory more efficiently than a class. IL does not support a struct type
directly. As IL does not recognise a structure, it does not enforce the following rules:
• Constructors must have parameters
• All members of a structure must be initialised before leaving the constructor.
Also, structures are derived from ValueType and not Object.
The type system of the .Net world is simplicity personified. It divides all the known types
into one of the two categories: a value type or a reference type.
• A reference type is known by a reference, that is, a memory location that stores the
address where the object resides in memory.
• A value type, however, is directly stored in the memory location occupied by the
variable that represents the type.
Value types are used to represent small data items like local variables, integers, numbers
with decimal places etc. The memory allocated is on the stack and not on the heap.
To access a reference type, the location of the variable in memory is to be first determined.
This is not true for a value type. Hence, there is no overhead of an indirection involved with
a value type and therefore, it is much more efficient.
The disadvantage of a value type is that they cannot be derived from and, if the data they
represent is fairly large, then copying the type on the stack is not an efficient way of
representing that type. There is no need to instantiate a variable of value type, as it is
already instantiated. Apart from these variations, value types are similar to reference types.

In the above example, we have created a value class or a value type called xxx, that has
two public fields i and j. We used the instruction initobj to create a new value type.
To display the value of i, we first created a local variable that represents our value class. In
our case, the variable is called v. ldloca is used to load the address of the variable v on the
stack. Then we called initobj with the name of the value class xxx as a parameter thus
creating a a new value type.
We, then, again load the address of the value type v on the stack and call ldfld. This
instruction needs the address of the value type on the stack to work with. The only reason
that the value of i is ZERO is that the instruction initobj guarantees that all members of
the value type will be initialized to zero.

The correct way to initialize a value class is to call the constructor. We first have to load
the address of the value type v on the stack. Then, since the constructor expects a single
parameter on the stack, we place the number 2 on the stack using ldc. The constructor is
then called in the same manner as we call any other function.
In the constructor, we first place the this pointer on the stack. The this pointer, or the first
invisible parameter to a function, is a reference to the starting location of the object in
memory. Parameter 1 is placed on the stack and stfld is called.
The constructor initializes all members of a value class. The static fields of a value class
are initialized when the value type is first loaded.

Not using initobj, like in the above example will assign a random value to the value type.
The use of initobj is optional. This instruction requires a managed pointer to an instance of
the value type and it is one of the few instructions that does not return anything on the
stack. The constructor is never called by the initobj instruction. The sole role initobj
performs is to initialize all the value class members to ZERO.
While verifying code, one should ensure that all the fields of a value type are assigned a
value before they are read or passed as parameters to a method. The code in constructor
assigns values to every field.
You can see the contrast between initobj and newobj. Value Types use initobj whereas
reference types use newobj. Also, value types are derived from System.ValueType.
Value types can have static, instance and virtual methods. Here, the static methods are
called in a similar manner when in a class.

To call an instance function of a value class, there is no need for either initobj or the
constructor call. But, it is a good practice to do so. We have to place the address of the
value type or the this pointer on the stack and then place the parameters. The function a1
uses the this pointer to access the fields.
We modified the function abc to read as follows:
.method public virtual instance void a1(int32 p) il managed
Despite making the function virtual, the program executes as before. The order of the
virtual modifier is very important.
You may recall that a virtual function has to be called using the instruction callvirt and not
the instruction call. However, in the case of a value class, we cannot use callvirt. Instead,
the instruction call is used.

In the above program, we specified an interface ddd, that contains a single function called
a1. We created a value class xxx that implements from ddd.
Our intention is to call the function a1 from the interface ddd. As mentioned earlier, to call
a function off an interface, the instruction callvirt has to be used and not the instruction
call, as, an interface does not contain any code.
The callvirt instruction requires a reference type on the stack because it does not work
with value types. Thus, we use ldloca to load the address of the value type on the stack.
Then, we use the box instruction to convert it into a reference type.

If we comment out the box instruction, the following exception is generated because callvirt
looks for a a boxed type on the stack:

The constructor assigns values to fields. It places the values on the stack and uses stfld to
assign the values to the fields. The question that arises is that what happens when we
equate reference objects with each other.
The explanation is very simple: A reference object is simply a memory location stored in a
local variable. The variable V_0 contains a reference to the newly created object in memory.
We place this value on the stack and use ldloc.1 to initialize the variable V_1 to this value.
Thus, a reference object is a number representing the memory location of an object. Here,
the same number is stored in the objects a and b. Hence b.i displays the number 10. Here,
the constructor does not get called again, as no new object is created.

This program and the next one should be read in conjunction if you want to grasp the
following:
• Concepts of boxing and unboxing
• The major difference between a class and a structure.
The concept of a structure is not supported by IL. On conversion to IL, a struct becomes a
class with the modifier value added to it. It is sealed and derived from ValueType hence
referred to as a value class.
In the C# program, an object is created, which is an instance of the structure xxx. The
constructor is passed the constant value 1, which is used to initialize the int field x to 1.
Then, the object b is initialized to a. Next, we change the value of the member x from 1 to 2
using the value object a.

We display the value of the field x using b. The cast operator is used as the data type of b
is Object and not xxx. We notice that there are two x ints in memory:
• One with a value of 2 that is associated with a,
• The other one with the value of 1 that is associated with b.
So much for the C# program, let us see as to what happens in our IL program. We create 3
objects in IL i.e. two variables V_1 and V_2 of the class xxx and one that looks like an
Object.
We place the address of V_0 on the stack followed by the value 1. Then, we call the
constructor using a call and not newobj, since we have a value class or structure and not a
pure class. The constructor initializes the field x to 1.
We have to convert this value class to a pure object that is an instance of the class Object.
We load the address of V_O and call the box instruction, which converts a value class into
a class and places the reference of the newly created object on the stack.
Then, we store this reference in the local variable V_1 using stloc.1. This is the code
generated when the statement object b = a is converted to IL. We have created a fresh
object using the box instruction. Thus there are two xxx objects in memory, one as the
value object V_0 and one as a reference object V_1.
We now need to initialize the field x to 2. To do so, the constant 2 is placed on the stack
and stfld is called. The easier part of the code is over.
The problem is in the expression WriteLine((xxx)b).x. The object b or V_1 is a reference
object. We have to cast it to a value object. To do this, we need to unbox it. The act of
converting a reference object to a value object is called unboxing. The unbox instruction
requires a reference type on the stack and it will place a value type whose data type is
specified by the name following xxx.
The instruction ldobj loads an instance of xxx on the stack whose pointer is already
present on the stack. We store this instance in V_2 and load this value type again on the
stack. Then we load the value of x and display it using WriteLine.

c is an object of type yyy and holds a value of 1 in its member x. Object d is another class
or call it a structure, it does not create a new object in memory but instead, points to the
same object referenced by c. Thus, we have one yyy object in memory, and any changes
made to the value of x using d will be reflected when using c and vice-versa.
Here, as we are dealing with a class, the instruction newobj is used to create it. To initialize
the object d to c, we first use ldloc.0 to place its value on the stack and then use the
instruction stloc.1 to initialize local V_1.
Then, we initialize c.x to 2 in the usual manner, by first placing the reference on the stack
using ldloc.0 and then, placing the value on the stack using stfld.
Object d is already a reference object and yyy is a class. Hence we simply use castclass. It
is easy to use casting here because neither boxing nor unboxing is required to be carried
out.
The important point to be mentioned is that we are not creating another yyy in memory,
and hence, there is only one field x in memory. This was not the case earlier case, when a
structure was used.

This example is deceptively similar to the one above.
First we take a reference object b and equate it to a value object f. Then we cast the
reference type object b to a value type int. The C# compiler gives us no errors but a
runtime exception is thrown.
Back to IL. We first create a long or an int64 V_0 using locals. Then we create an Object
V_1 and finally an int V_2.
We thereafter, place 1 on the stack, convert it into 8 bytes using conv.i8 and use stloc.0 to
store the value in V_0. The address is then placed on the stack, as we need to use the box
instruction to convert it into a reference type, which is finally to be stored in b or V_1.
Unbox the object b, the one created out of a value type, and store in an int. To do this, we
need to place a reference on the stack and call unbox. This will place a value address on
the stack and use ldind.i4 to fetch the value stored at this address. Then, we use stloc.2 to
initialize the variable V_2. The exception clearly states that we cannot cast an object that is
a reference type to a value type.

Languages decide on how you write code and name variables. In C# a field and a parameter
to a function can have the same names, but the parameter name has more visibility than
the field name.
this.x refers to the field name in the function abc unlike the parameter named x. In IL, this
dilemma does not arise, as we have one set of instructions that deals with fields, a second
set that deals with parameters to functions and a third set that deals with locals. Thus
there is no way that a name clash can ever occur.

We take one more program on structures before we close this chapter. . We have created a
struct containing a field i and a function abc. Structures are value objects and are stored
on the stack and not on the heap. Thus, the word value has been used in the locals
directive. It is a class, but of a value type.
In the definition of the structure, we have added two modifiers, sealed and value

Therefore, we cannot derive from this value class. Everything else is similar to a class.