Boxed Types

For every value type, including user-defined value types, there exist a corresponding object type, known as its boxed type. The CLR automatically generates boxed types for user-defined value types, which means that values of any value type can be boxed and unboxed:

• Boxing a value type copies the data from the value into an object of its boxed type allocated on the garbage collected heap.


• UnBoxing a value type returns a pointer to the actual data—that is, the sequence of bits—held in a boxed object. (In some programming languages, unboxing not only facilitates obtaining the pointer to the data members of a boxed object but also copies the data from the boxed object into a value of the value type on the stack.)

Reference Types

Reference Types combine the address of a value (known as its identity) and the value's sequence of bits. Reference types can, therefore, be compared using both identity and equality. Identity means that two references refer to the same object; equality means that two references refer to two different objects that have the same data—that is, the same sequence of bits. References types differ from value types in the following ways:

• Value types always directly inherit from System.ValueType or System.Enum , which itself inherits from System.ValueType . The types are always sealed, which means that no other types can inherit from them. Reference types, in contrast, inherit from any class other than System.ValueType or System.Enum .


• Reference types are always allocated on the garbage collected heap, whereas value types are normally allocated on the stack. However, that value types may be allocated on the garbage collected heap—for instance, as members of reference types.


• Reference types are accessed via strongly typed references. These references are updated if the garbage collector moves an object.

Note:- All types derive from System.Object base type are reference types.

1] Object Types  

All object types inherit, either directly or indirectly, from the CLR type System.Object class. A major facility of the Object class is its ability to enforce a singular rooted inheritance hierarchy on all types in the CLR. Although you may think that this kind of inheritance does not apply to value types, value types can be treated as a subtype of Object through boxing. The libraries make extensive use of the Object type as the parameters to, and the return type of, many functions.

The Object class provides a number of methods that can be called on all objects:

• Equals: returns true if the two objects are equal. Subtypes may override this method to provide either identity or equality comparison. Equals is available as both a virtual method that takes a single parameter consisting of the other object with which this object is being compared and a static method that, naturally, requires two parameters.


• Finalize: is invoked by the garbage collector before an object's memory is reclaimed. Because the garbage collector is not guaranteed to run during a program's execution, this method may not be invoked. In C#, if a developer defines a destructor, then it is renamed to be the type's Finalize method.


• GetType: returns the type object for this object. This method gives access to the metadata for the object. A static method on the Type class can be used for the same purpose; it does not require that an instance of the class be created first.


• GetHashCode: returns a hash code for an object. It can be used when inserting objects into containers that require a key to be associated with each such object.


• ToString: returns a string that represents the object. As defined in Object , this method returns the name of the type of the object—that is, its exact type. Subtypes may override this method to have the return string represent the object as the developer sees fit. For example, the String class returns the value of the string and not the name of the String class

2] Interface Types

Interface-based programming is the predominate paradigm. Object-oriented programmers will already be familiar with the concept of substituting a derived type for a base type. Interface implements the concept of multiple inheritances.

An interface type is a partial specification of a type. This contract binds implementers to providing implementations of the members contained in the interface. Object types may support many interface types, and many different object types would normally support an interface type. By definition, an interface type can never be an object type or an exact type. Interface types may extend other interface types; that is, an interface type can inherit from other interface types. An interface type may define the following:

• Methods (static and instance)


• Fields (static)


• Properties


• Events

Pointer Types

Pointer types provide a means of specifying the location of either code or a value. The CLR supports three pointer types:

• Unmanaged function pointers refer to code and are similar to function pointers in C++ i.e. delegates.


• Managed Pointers are known to the garbage collector and are updated if they refer to an item that is moved on the garbage collected heap. Unmanaged pointers are similar to unmanaged function pointers but refer to values. Unmanaged pointers are not CLS compliant, and many languages do not even expose syntax to define or use them. By comparison, managed pointers can point at items located on the garbage collected heap and are CLS compliant.

Common Type System:

In order that two languages communicate smoothly CLR has CTS (Common Type System). Example VB you have “Integer” and in C++ you have “long” these data types are not compatible so that interfacing between them is very complicated.

In order that two different languages can communicate Microsoft introduced CTS so “Integer” data type in VB6 and “int” data type in C++ will convert it to System.int32 which is data type of CTS.CLS