Thanks to visit codestin.com
Credit goes to www.scribd.com

0% found this document useful (0 votes)
51 views2 pages

Values and Objects: Common Type System Classification of Types

The document discusses the common type system which categorizes types into two general categories: value types and reference types. Value types directly contain data and are stored on the stack or inline, while reference types store a reference to the memory address and are stored on the heap. All types derive from the System.Object base type. The document also discusses how types relate to assemblies and namespaces at runtime.

Uploaded by

Suresh Kumar
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
51 views2 pages

Values and Objects: Common Type System Classification of Types

The document discusses the common type system which categorizes types into two general categories: value types and reference types. Value types directly contain data and are stored on the stack or inline, while reference types store a reference to the memory address and are stored on the heap. All types derive from the System.Object base type. The document also discusses how types relate to assemblies and namespaces at runtime.

Uploaded by

Suresh Kumar
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 2

Common Type System

Classification of Types

The common type system supports two general categories of types, each of which is
further divided into subcategories:
• Value types
Value types directly contain their data, and instances of value types are either
allocated on the stack or allocated inline in a structure. Value types can be
built-in (implemented by the runtime), user-defined, or enumerations. For a
list of built-in value types, see the .NET Framework Class Library.
• Reference types
Reference types store a reference to the value's memory address, and are
allocated on the heap. Reference types can be self-describing types, pointer
types, or interface types. The type of a reference type can be determined from
values of self-describing types. Self-describing types are further split into
arrays and class types. The class types are user-defined classes, boxed value
types, and delegates.
Variables that are value types each have their own copy of the data, and therefore
operations on one variable do not affect other variables. Variables that are reference
types can refer to the same object; therefore, operations on one variable can affect the
same object referred to by another variable.

All types derive from the System.Object base type.

The following diagram illustrates how these various types are related. Note that
instances of types can be simply value types or self-describing types, even though
there are subcategories of these types.

Type classification

For more information about each type, see value types, enumerations, classes,
delegates, arrays, interfaces, and pointers.

Values and Objects


Values are binary representations of data, and types provide a way of interpreting this
data. A value type is stored directly as a binary representation of the type's data. The
value of a reference type is the location of the sequence of bits that represent the
type's data.

Every value has an exact type that completely defines the value's representation and
the operations that are defined on the value. Values of self-describing types are called
objects. While it is always possible to determine the exact type of an object by
examining its value, you cannot do so with a value type or pointer type. A value can
have more than one type. A value of a type that implements an interface is also a
value of that interface type. Likewise, a value of a type that derives from a base type
is also a value of that base type.

Types and Assemblies


The runtime uses assemblies to locate and load types. The assembly manifest contains
the information that the runtime uses to resolve all type references made within the
scope of the assembly.

A type name in the runtime has two logical parts: the assembly name and the name of
the type within the assembly. Two types with the same name but in different
assemblies are defined as two distinct types.

Assemblies provide consistency between the scope of names seen by the developer
and the scope of names seen by the runtime system. Developers author types in the
context of an assembly. The content of the assembly a developer is building
establishes the scope of names that will be available at run time.

Types and Namespaces


From the viewpoint of the runtime, a namespace is just a collection of type names.
Particular languages might have constructs and corresponding syntax that help
developers form logical groups of types, but these constructs are not used by the
runtime when binding types. Thus, both the Object and String classes are part of the
System namespace, but the runtime only recognizes the full names of each type,
which are System.Object and System.String, respectively.

You can build a single assembly that exposes types that look like they come from two
different hierarchical namespaces, such as System.Collections and
System.Windows.Forms. You can also build two assemblies that both export types
whose names contain MyDll.MyClass.

If you create a tool to represent types in an assembly as belonging to a hierarchical


namespace, the tool must enumerate the types in an assembly or group of assemblies
and parse the type names to derive a hierarchical relationship.

You might also like