Part II Designing Types in VS .NET

Print QR Code JIS X 0510 in VS .NET Part II Designing Types

// Box v and store the reference pointer in o. IL_0002: ldloc.0 IL_0003: box [mscorlib]System.Int32 IL_0008: stloc.1 // Load 123 into v. IL_0009: ldc.i4.s IL_000b: stloc.0

// Box v and leave the pointer on the stack for Concat. IL_000c: ldloc.0 IL_000d: box [mscorlib]System.Int32 // Load the string on the stack for Concat. IL_0012: ldstr ", " // Load the address of the boxed Int32 on the stack for Concat. IL_0017: ldloc.1 // Call Concat. IL_0018: call

string [mscorlib]System.String::Concat(object, object, object)

// The string returned from Concat is passed to WriteLine. IL_001d: call void [mscorlib]System.Console::WriteLine(string) // Return from Main terminating this application. IL_0022: ret } // end of method App::Main

A quick comparison of the IL for these two versions of the Main method shows that the version without the (Int32) cast is 10 bytes smaller than the version with the cast . The extra unbox/box steps in the first version are obviously generating more code . An even bigger concern, however, is that the extra boxing step allocates an additional object from the managed heap that must be garbage collected in the future . Certainly, both versions give identical results, and the difference in speed isn t noticeable, but extra, unnecessary boxing operations occurring in a loop cause the performance and memory usage of your application to be seriously degraded . You can improve the previous code even more by calling WriteLine like this:

Console.WriteLine(v.ToString() + ", " + o); // Displays "123, 5"

Now ToString is called on the unboxed value type instance v, and a String is returned . String objects are already reference types and can simply be passed to the Concat method without requiring any boxing . Let s look at yet another example that demonstrates boxing and unboxing:

public static void Main() { Int32 v = 5; Object o = v; v = 123; Console.WriteLine(v); v = (Int32) o; Console.WriteLine(v); } // Create an unboxed value type variable. // o refers to the boxed version of v. // Changes the unboxed value type to 123 // Displays "123" // Unboxes and copies o into v // Displays "5"

How many boxing operations do you count in this code The answer is one . The reason that there is only one boxing operation is that the System.Console class defines a WriteLine method that accepts an Int32 as a parameter:

public static void WriteLine(Int32 value);

In the two calls to WriteLine above, the variable v, an Int32 unboxed value type instance, is passed by value . Now it may be that WriteLine will box this Int32 internally, but you have no control over that . The important thing is that you ve done the best you could and have eliminated the boxing from your own code . If you take a close look at the FCL, you ll notice many overloaded methods that differ based on their value type parameters . For example, the System.Console type offers several overloaded versions of the WriteLine method:

public public public public public public public public public public public public static static static static static static static static static static static static void void void void void void void void void void void void WriteLine(Boolean); WriteLine(Char); WriteLine(Char[]); WriteLine(Int32); WriteLine(UInt32); WriteLine(Int64); WriteLine(UInt64); WriteLine(Single); WriteLine(Double); WriteLine(Decimal); WriteLine(Object); WriteLine(String);

You ll also find a similar set of overloaded methods for System.Console s Write method, System.IO.BinaryWriter s Write method, System.IO.TextWriter s Write and WriteLine methods, System.Runtime.Serialization.SerializationInfo s AddValue method, System.Text.StringBuilder s Append and Insert methods, and so on . Most of these methods offer overloaded versions for the sole purpose of reducing the number of boxing operations for the common value types . If you define your own value type, these FCL classes will not have overloads of these methods that accept your value type . Furthermore, there are a bunch of value types already defined in the FCL for which overloads of these methods do not exist . If you call a method that does not have an overload for the specific value type that you are passing to it, you will always end