Scribd
Upload
9 views2 pages

Delegates Part 4

The document discusses the Delegate and MulticastDelegate classes in the .NET Framework. It describes how they were originally separate classes but are now merged, with all delegate types deriving from MulticastDelegate. It also explains how to compare delegates for equality.

Uploaded by

dean36712
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
9 views2 pages

Delegates Part 4

The document discusses the Delegate and MulticastDelegate classes in the .NET Framework. It describes how they were originally separate classes but are now merged, with all delegate types deriving from MulticastDelegate. It also explains how to compare delegates for equality.

Uploaded by

dean36712
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 2

The .NET Framework Class Library defines the System.MulticastDelegate class.

This is the class that I


discussed in my April 2001 column. However, you should be aware that MulticastDelegate is actually
derived from the System.Delegate class (also defined in the .NET Framework Class Library), which itself
is derived from System.Object.
When originally designing the .NET Framework, Microsoft engineers felt the need to provide two
different types of delegates: single-cast and multicast. MulticastDelegate-derived types would represent
delegate objects that could be chained together and Delegate-derived types would represent objects that
could not be chained together. The System.Delegate type was designed as the base type, and this class
implemented all of the functionality necessary to call back a wrapped method. The MulticastDelegate
class was derived from the Delegate class and added the ability to create a linked list (or chain) of
MulticastDelegate objects.
When compiling source code, a compiler would check the delegate�s signature and select the more
appropriate of the two classes for the compiler-generated delegate type’s base class. For the curious,
methods with a signature that indicated a void return value would be derived from System.Delegate, while
methods with a non-void return value would be derived from System.MulticastDelegate. This made sense
since you can only get the return value from the last method called in a linked-list chain.
During the beta testing of the .NET Framework, it became clear that having the two different base
types confused developers. In addition, designing delegates this way placed arbitrary limitations on them.
For example, many methods have return values that, in many situations, can be ignored. Since these
methods would have a non-void return value, they wouldn�t be derived from the MulticastDelegate class,
preventing them from being combined into a linked-list.
To reduce developer confusion, Microsoft engineers wanted to merge the Delegate and
MulticastDelegate classes together into a single class that allowed any delegate object to participate in a
linked-list chain. All compilers would generate delegate classes deriving from this one class. This change
would reduce complexity and effort for the .NET Framework team, the common language runtime (CLR)
team, the compiler teams, and for third-party developers in the field who are using delegates.
Unfortunately, the idea of merging the Delegate and MulticastDelegate classes came along a bit late
in the .NET Framework development cycle and Microsoft was concerned about the potential bugs and
testing hit that would occur if they actually made all the necessary changes. So, in Beta 1 of the .NET
Framework, these classes have not been merged. You should certainly expect them to be merged into a
single class in a future version of the .NET Framework.
While Microsoft chose to delay the merging of these two classes in the .NET Framework Class
Library, they did modify all of the Microsoft compilers so that they now generate delegate types derived
from the MulticastDelegate class all the time. So, in my last column when I said that all delegate types are
derived from MulticastDelegate, I was not lying. Because of this change to the compiler, all instances of
delegate types can be combined into a linked-list chain regardless of the callback method’s return value.
So why do you need to understand all of this? As you start working more and more with delegates,
you will certainly run across both the Delegate and MulticastDelegate types in the .NET Framework SDK
documentation. I wanted you to understand the relationship between these two classes. In addition, even
though all delegate types you create have MulticastDelegate as a base class, you will occasionally
manipulate your types using methods defined by the Delegate class instead of the MulticastDelegate
class.
For example, the Delegate class has static methods called Combine and Remove. (I’ll explain what
these methods do later.) The signatures for both of these methods indicate that they take Delegate
parameters. Since your delegate type is derived from MulticastDelegate, which, in turn, is derived from
Delegate, instances of your delegate type may be passed to the Combine and Remove methods.

Comparing Delegates for Equality

The Delegate base class overrides Object’s virtual Equals method. The MulticastDelegate type
inherits Delegate’s implementation of Equals. Delegate’s implementation of Equals compares two
delegate objects to see if their _target and _methodPtr fields refer to the same object and method. If
these two fields match, then Equals returns true; otherwise Equals returns false. The following code
demonstrates this:
// Construct 2 delegate objects that refer to the
// same target/method
Feedback fb1 = new Feedback(FeedbackToConsole);
Feedback fb2 = new Feedback(FeedbackToConsole);

// Even though fb1 and fb2 refer to two different objects


// internally, they both refer to the same callback
// target/method.
Console.WriteLine(fb1.Equals(fb2)); // Displays "True"

In addition, both the Delegate and MulticastDelegate types provide overloads for the equality (==)
and inequality (!=) operators. Therefore, you can use these operators instead of calling the Equals
method. The following code is identical to that shown above:

// Construct 2 delegate objects that refer to the same target/method


Feedback fb1 = new Feedback(FeedbackToConsole);
Feedback fb2 = new Feedback(FeedbackToConsole);

// Even though fb1 and fb2 refer to two different objects internally,
// they both refer to the same callback target/method.
Console.WriteLine(fb1 == fb2); // Displays "True"

You might also like