CLR via C# 3rd - 05 - Primitive, Reference, and Value Types
1. Primitive Types
Any data types the compiler directly supports are called primitive types.
Primitive types map directly to types existing in the Framework Class Library (FCL).
For the types that are compliant with the Common Language Specification (CLS), other languages will offer similar primitive types. However, languages aren’t required to offer any support for the non–CLS-compliant types.
Primitives with Corresponding FCL Types
Another way to think of this is that the C# compiler automatically assumes that you have the following using directives in all of your source code files.
using sbyte = System.SByte;using byte = System.Byte;using short = System.Int16;using ushort = System.UInt16;using int = System.Int32;using uint = System.UInt32;...
About the compiler:
First, the compiler is able to perform implicit or explicit casts between primitive types. C# allows implicit casts if the conversion is “safe,” that is, no loss of data is possible. C# requires explicit casts if the conversion is potentially unsafe. For numeric types, “unsafe” means that you could lose precision or magnitude as a result of the conversion.
Be aware that different compilers can generate different code to handle these cast operations. For example, when casting a Single with a value of 6.8 to an Int32, some compilers could generate code to put a 6 in the Int32, and others could perform the cast by rounding the result up to 7. By the way, C# always truncates the result.
In addition to casting, primitive types can be written as literals.
If you have an expression consisting of literals, the compiler is able to evaluate the expression at compile time, improving the application’s performance.
2. Checked and Unchecked Primitive Type Operations
The CLR offers IL instructions that allow the compiler to choose the desired behavior. The CLR has an instruction called add that adds two values together. The add instruction performs no overflow checking. The CLR also has an instruction called add.ovf that also adds two values together. However, add.ovf throws a System.OverflowException if an overflow occurs. In addition to these two IL instructions for the add operation, the CLR also has similar IL instructions for subtraction (sub/sub.ovf), multiplication (mul/mul.ovf), and data conversions (conv/conv.ovf).
One way to get the C# compiler to control overflows is to use the /checked+ compiler switch. This switch tells the compiler to generate code that has the overflow-checking versions of the add, subtract, multiply, and conversion IL instructions. The code executes a little slower because the CLR is checking these operations to determine whether an overflow occurred. If an overflow occurs, the CLR throws an OverflowException.
In addition to having overflow checking turned on or off globally, programmers can control overflow checking in specific regions of their code. C# allows this flexibility by offering checked and unchecked operators.
e.g
UInt32 invalid = unchecked((UInt32) (-1)); // OKByte b = 100;b = checked((Byte) (b + 200)); // OverflowException is thrownb = (Byte) checked(b + 200); // b contains 44; no OverflowException
In addition to the checked and unchecked operators, C# also offers checked and unchecked statements. The statements cause all expressions within a block to be checked or unchecked.
e.g
checked { // Start of checked blockByte b = 100;b = (Byte) (b + 200); // This expression is checked for overflow.}
In fact, if you use a checked statement block, you can now use the += operator with the Byte, which simplifies the code a bit:
e.g
checked { // Start of checked blockByte b = 100;b += 200; // This expression is checked for overflow.}
Important: Because the only effect that the checked operator and statement have is to determine which versions of the add, subtract, multiply, and data conversion IL instructions are produced, calling a method within a checked operator or statement has no impact on that method, as the following code demonstrates:
checked {// Assume SomeMethod tries to load 400 into a Byte.SomeMethod(400);// SomeMethod might or might not throw an OverflowException.// It would if SomeMethod were compiled with checked instructions.}
Some recommended rules to programmers
(1) Use signed data types (such as Int32 and Int64) instead of unsigned numeric types (such as UInt32 and UInt64) wherever possible.
(2) As you write your code, explicitly use checked around blocks where an unwanted overflow might occur due to invalid input data
(3) As you write your code, explicitly use unchecked around blocks where an overflow is OK, such as calculating a checksum
(4) For any code that doesn’t use checked or unchecked, the assumption is that you do want an exception to occur on overflow.
Important: The System.Decimal type is a very special type. Although many programming languages (C# and Visual Basic included) consider Decimal a primitive type, the CLR does not. This means that the CLR doesn’t have IL instructions that know how to manipulate a Decimal value. If you look up the Decimal type in the .NET Framework SDK documentation, you’ll see that it has public static methods called Add, Subtract, Multiply, Divide, and so on. In addition, the Decimal type provides operator overload methods for +, -, *, /, and so on.
When you compile code that uses Decimal values, the compiler generates code to call Decimal’s members to perform the actual operation. This means that manipulating Decimal values is slower than manipulating CLR primitive values. Also, because there are no IL instructions for manipulating Decimal values, the checked and unchecked operators, statements, and compiler switches have no effect. Operations on Decimal values always throw an OverflowException if the operation can’t be performed safely.
Similarly, the System.Numerics.BigInteger type is also special in that it internally uses an array of UInt32s to represent an arbitrarily large integer whose value has no upper or lower bound. Therefore, operations on a BigInteger never result in an OverflowException. However, a BigInteger operation may throw an OutOfMemoryException if the value gets too large and there is insufficient available memory to resize the array.
3. Reference Types and Value Types
The CLR supports two kinds of types: reference types and value types.
In C#, types declared using struct are value types, and types declared using class are reference types.
Value type instances are usually allocated on a thread’s stack (although they can also be embedded as a field in a reference type object). The variable representing the instance doesn’t contain a pointer to an instance; the variable contains the fields of the instance itself.
Reference types are always allocated from the managed heap, and the C# new operator returns the memory address of the object—the memory address refers to the object’s bits.
All of the structures are immediately derived from the System.ValueType abstract type. System.ValueType is itself immediately derived from the System.Object type. By definition, all value types must be derived from System.ValueType. All enumerations are derived from the System.Enum abstract type, which is itself derived from System.ValueType. The CLR and all programming languages give enumerations special treatment.
In addition, all value types are sealed, which prevents a value type from being used as a base type for any other reference type or value type
Important For many developers (such as unmanaged C/C++ developers), reference types and value types will seem strange at first. In unmanaged C/C++, you declare a type, and then the code that uses the type gets to decide if an instance of the type should be allocated on the thread’s stack or in the application’s heap.
In managed code, the developer defining the type indicates where instances of the type are allocated; the developer using the type has no control over this.
4. CLR controls the Layout of Type's Fields
To improve performance, the CLR is capable of arranging the fields of a type any way it chooses.
You tell the CLR what to do by applying the System.Runtime.InteropServices. StructLayoutAttribute attribute on the class or structure you’re defining. To this attribute’s constructor, you can pass LayoutKind.Auto to have the CLR arrange the fields, LayoutKind.Sequential to have the CLR preserve your field layout, or LayoutKind.Explicit to explicitly arrange the fields in memory by using offsets. If you don’t explicitly specify the StructLayoutAttribute on a type that you’re defining, your compiler selects whatever layout it determines is best.
You should be aware that Microsoft’s C# compiler selects LayoutKind.Auto for reference types (classes) and LayoutKind.Sequential for value types (structures).
The StructLayoutAttribute also allows you to explicitly indicate the offset of each field by passing LayoutKind.Explicit to its constructor. Then you apply an instance of the System.Runtime.InteropServices.FieldOffsetAttribute attribute to each field passing to this attribute’s constructor an Int32 indicating the offset (in bytes) of the field’s first byte from the beginning of the instance. Explicit layout is typically used to simulate what would be a union in unmanaged C/C++ because you can have multiple fields starting at the same offset in memory.
The Differences between Value Type and Reference Type:
(1) Value type objects have two representations: an unboxed form and a boxed form. Reference types are always in a boxed form.
(2) Value types are derived from System.ValueType. This type offers the same methods as defined by System.Object. However, System.ValueType overrides the Equals method so that it returns true if the values of the two objects’ fields match. In addition, System.ValueType overrides the GetHashCode method to produce a hash code value by using an algorithm that takes into account the values in the object’s instance fields.
(3) Because you can’t define a new value type or a new reference type by using a value type as a base class, you shouldn’t introduce any new virtual methods into a value type. No methods can be abstract, and all methods are implicitly sealed (can’t be overridden).
(4) Reference type variables contain the memory address of objects in the heap. By default, when a reference type variable is created, it is initialized to null, indicating that the reference type variable doesn’t currently point to a valid object. Attempting to use a null reference type variable causes a NullReferenceException to be thrown. By contrast, value type variables always contain a value of the underlying type, and all members of the value type are initialized to 0. Since a value type variable isn’t a pointer, it’s not possible to generate a NullReferenceException when accessing a value type. The CLR does offer a special feature that adds the notion of nullability to a value type. This feature, called nullable types.
(5) When you assign a value type variable to another value type variable, a field-by-field copy is made. When you assign a reference type variable to another reference type variable, only the memory address is copied.
(6) Two or more reference type variables can refer to a single object in the heap, allowing operations on one variable to affect the object referenced by the other variable. On the other hand, value type variables are distinct objects, and it’s not possible for operations on one value type variable to affect another
(7) Because unboxed value types aren’t allocated on the heap, the storage allocated for them is freed as soon as the method that defines an instance of the type is no longer active. This means that a value type instance doesn’t receive a notification (via a Finalize method) when its memory is reclaimed.
4. Boxing and Unboxing Value Types
It’s possible to convert a value type to a reference type by using a mechanism called boxing.
Internally, here’s what happens when an instance of a value type is boxed:
1. Memory is allocated from the managed heap. The amount of memory allocated is the size required by the value type’s fields plus the two additional overhead members (the type object pointer and the sync block index) required by all objects on the managed heap.
2. The value type’s fields are copied to the newly allocated heap memory.
3. The address of the object is returned. This address is now a reference to an object; the value type is now a reference type.
When trying convert reference type to value type. Two steps to accomplish the progress:
First, the address of the value type's fields in the boxed value type's object is obtained. This process is called unboxing.
Then, the values of these fields are copied from the heap to the stack-based value type instance.
Unboxing is not the exact opposite of boxing. The unboxing operation is much less costly than boxing.
Unboxing is really just the operation of obtaining a pointer to the raw value type (data fields) contained within an object. In effect, the pointer refers to the unboxed portion in the boxed instance. So, unlike boxing, unboxing doesn’t involve the copying of any bytes in memory. Having made this important clarification, it is important to note that an unboxing operation is typically followed by copying the fields.
Unboxed value types are lighter-weight types than reference types for two reasons:
(1) They are not allocated on the managed heap.
(2) They don’t have the additional overhead members that every object on the heap has: a type object pointer and a sync block index.
Because unboxed value types don’t have a sync block index, you can’t have multiple threads synchronize their access to the instance by using the methods of the System.Threading.Monitor type
5. Changing Fields in a Boxed Value Type by Using Interfaces
6. Object Equality and Identity
The System.Object type offers a virtual method named Equals, whose purpose is to return true if two objects contain the same value. The implementation of Object’s Equals method looks like this:
public class Object {public virtual Boolean Equals(Object obj) {// If both references point to the same object,// they must have the same value.if (this == obj) return true;// Assume that the objects do not have the same value.return false;}}
At first, this seems like a reasonable default implementation of Equals: it returns true if the this and obj arguments refer to the same exact object. This seems reasonable because Equals knows that an object must have the same value as itself. However, if the arguments refer to different objects, Equals can’t be certain if the objects contain the same values, and therefore, false is returned. In other words, the default implementation of Object’s Equals method really implements identity, not value equality.
Here is how to properly implement an Equals method internally
1. If the obj argument is null, return false because the current object identified by this is obviously not null when the nonstatic Equals method is called.
2. If the this and obj arguments refer to the same object, return true. This step can improve performance when comparing objects with many fields.
3. If the this and obj arguments refer to objects of different types, return false. Obviously, checking if a String object is equal to a FileStream object should result in a false result.
4. For each instance field defined by the type, compare the value in the this object with the value in the obj object. If any fields are not equal, return false.
5. Call the base class’s Equals method so it can compare any fields defined by it. If the base class’s Equals method returns false, return false; otherwise, return true.
So Microsoft should have implemented Object’s Equals like this:
e.g
public class Object {public virtual Boolean Equals(Object obj) {// The given object to compare to can't be nullif (obj == null) return false;// If objects are different types, they can't be equal.if (this.GetType() != obj.GetType()) return false;// If objects are same type, return true if all of their fields match// Since System.Object defines no fields, the fields matchreturn true;}}
But, since Microsoft didn’t implement Equals this way, the rules for how to implement Equals are significantly more complicated than you would think. When a type overrides Equals, the override should call its base class’s implementation of Equals unless it would be calling Object’s implementation. This also means that since a type can override Object’s Equals method, this Equals method can no longer be called to test for identity. To fix this, Object offers a static ReferenceEquals method, which is implemented like this:
public class Object {public static Boolean ReferenceEquals(Object objA, Object objB) {return (objA == objB);}}
You should always call ReferenceEquals if you want to check for identity (if two references point to the same object). You shouldn’t use the C# == operator (unless you cast both operands to Object first) because one of the operands’ types could overload the == operator, giving it semantics other than identity.
As you can see, the .NET Framework has a very confusing story when it comes to object equality and identity. By the way, System.ValueType (the base class of all value types) does override Object’s Equals method and is correctly implemented to perform a value equality check (not an identity check). Internally, ValueType’s Equals is implemented this way:
1. If the obj argument is null, return false.
2. If the this and obj arguments refer to objects of different types, return false.
3. For each instance field defined by the type, compare the value in the this object withthe value in the obj object by calling the field’s Equals method. If any fields are notequal, return false.
4. Return true. Object’s Equals method is not called by ValueType’s Equals method.
Internally, ValueType’s Equals method uses reflection in step #3.
The four properties of equality
.. Equals must be reflexive; that is, x.Equals(x) must return true.
.. Equals must be symmetric; that is, x.Equals(y) must return the same value as y.Equals(x).
.. Equals must be transitive; that is, if x.Equals(y) returns true and y.Equals(z) returns true, then x.Equals(z) must also return true.
.. Equals must be consistent. Provided that there are no changes in the two values being compared, Equals should consistently return true or false.
When overriding the Equals method, there are a few more things that you’ll probably want to do:
.. Have the type implement the System.IEquatable<T> interface’s Equals method
This generic interface allows you to define a type-safe Equals method. Usually, you’ll implement the Equals method that takes an Object parameter to internally call the type-safe Equals method
.. Overload the == and !=operator methods
Usually, you’ll implement these operator methods to internally call the type-safe Equals method.
7. Object Hash Codes
The designers of the FCL decided that it would be incredibly useful if any instance of any object could be placed into a hash table collection. To this end, System.Object provides a virtual GetHashCode method so that an Int32 hash code can be obtained for any and all objects.
If you define a type and override the Equals method, you should also override the GetHashCode method. In fact, Microsoft’s C# compiler emits a warning if you define a type that overrides Equals without also overriding GetHashCode.
The reason why a type that defines Equals must also define GetHashCode is that the implementation of the System.Collections.Hashtable type, the System.Collections. Generic.Dictionary type, and some other collections require that any two objects that are equal must have the same hash code value. So if you override Equals, you should override GetHashCode to ensure that the algorithm you use for calculating equality corresponds to the algorithm you use for calculating the object’s hash code.
Defining a GetHashCode method can be easy and straightforward. But depending on your data types and the distribution of data, it can be tricky to come up with a hashing algorithm that returns a well-distributed range of values. Here’s a simple example that will probably work just fine for Point objects:
internal sealed class Point {private readonly Int32 m_x, m_y;public override Int32 GetHashCode() {return m_x ^ m_y; // m_x XOR'd with m_y}...}
When selecting an algorithm for calculating hash codes for instances of your type, try to follow these guidelines:
.. Use an algorithm that gives a good random distribution for the best performance of the hash table.
.. Your algorithm can also call the base type’s GetHashCode method, including its return value. However, you don’t generally want to call Object’s or ValueType’s GetHashCode method, because the implementation in either method doesn’t lend itself to highperformance hashing algorithms.
.. Your algorithm should use at least one instance field.
.. Ideally, the fields you use in your algorithm should be immutable; that is, the fields should be initialized when the object is constructed, and they should never again change during the object’s lifetime.
.. Your algorithm should execute as quickly as possible.
.. Objects with the same value should return the same code. For example, two String objects with the same text should return the same hash code value.
System.Object’s implementation of the GetHashCode method doesn’t know anything about its derived type and any fields that are in the type. For this reason, Object’s GetHashCode method returns a number that is guaranteed to uniquely identify the object within the AppDomain; this number is guaranteed not to change for the lifetime of the object. After the object is garbage collected, however, its unique number can be reused as the hash code for a new object.
Note If a type overrides Object’s GetHashCode method, you can no longer call it to get a unique ID for the object. If you want to get a unique ID (within an AppDomain) for an object, the FCL provides a method that you can call. In the System.Runtime.CompilerServices namespace, see the RuntimeHelpers class’s public, static GetHashCode method that takes a reference to an Object as an argument. RuntimeHelpers’ GetHashCode method returns a unique ID for an object even if the object’s type overrides Object’s GetHashCode method. This method got its name because of its heritage, but it would have been better if Microsoft had named it something like GetUniqueObjectID.
System.ValueType’s implementation of GetHashCode uses reflection (which is slow) and XORs some of the type’s instance fields together. This is a naïve implementation that might be good for some value types, but I still recommend that you implement GetHashCode yourself because you’ll know exactly what it does, and your implementation will be faster than ValueType’s implementation.
8. Dynamic Primitive Type
Important Do not confuse dynamic and var. Declaring a local variable using var is just a syntactical shortcut that has the compiler infer the specific data type from an expression. The var keyword can be used only for declaring local variables inside a method while the dynamic keyword can be used for local variables, fields, and arguments. You cannot cast an expression to var but you can cast an expression to dynamic. You must explicitly initialize a variable declared using var while you do not have to initialize a variable declared with dynamic.
Important A dynamic expression is really the same type as System.Object. The compiler assumes that whatever operation you attempt on the expression is legal, so the compiler will not generate any warnings or errors. However, exceptions will be thrown at runtime if you attempt to execute an invalid operation. In addition, Visual Studio cannot offer any IntelliSense support to help you write code against a dynamic expression. You cannot define an extension method that extends dynamic, although you can define one that extends Object. And, you cannot pass a lambda expression or anonymous method as an argument to a dynamic method call since the compiler cannot infer the types being used.
