Scribd
Upload
5 views

complete-reference-vb_net_8

Uploaded by

khalid
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
5 views

complete-reference-vb_net_8

Uploaded by

khalid
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 1

Delegates vs.

Function Pointers
Having implemented both models in this chapter we can arrive at a conclusion that the .NET Framework is
flexible enough to accommodate both event models. In some scenarios, adapter interfaces are a better fit,
while in other instances Delegates do a better job. Claiming that Delegates detract from the OO'ness of .NET
is a matter of personal conviction. Delegate syntax and semantics do not detract from the overall OO
semantics of .NET programming at all.

An explosion of interfaces does not impact the application any more than an explosion of Delegates does.
There can be problems, however, with the overhead of the additional adapter classes in an extensive
event−driven application. The additional code adds upa situation that is alleviated with a method pointer,
which doesn't impact the Receiver in any way.

Delegates, like Adapter classes, are more useful for event processing. For example, you might want an object
that raises events to be able to call different event handlers under different circumstances. Unfortunately, the
object−raising events cannot know ahead of time which event handler is managing a specific event. Visual
Basic .NET lets you dynamically associate event handlers with events by creating a Delegate for you when
you use the AddHandler statement. At runtime, the Delegate forwards calls to the appropriate event handler.

Although you can create your own Delegates, in most cases Visual Basic .NET automatically generates the
Delegate and takes care of the details for you. For example, an Event statement implicitly defines a Delegate
class named EventName .EventHandler as a nested class of the class containing the Event statementand
with the same signature as the event. The AddressOf statement implicitly creates an instance of a Delegate.

Delegates vs. Function Pointers

Since Delegates are a form of method pointer, it is useful to compare them to function pointers. It can be said
that Delegates address many of the scenarios addressed by function pointers. The latter do not belong in
.NET, just as they do not belong in any true OO framework. The additional effort to protect the
object−orientation, type safety, and security of the runtime would not be worth the effort. But for interest's
sake, and to enable us to understand Delegates more, let's see how Delegates differ from C++−style function
pointers.

• Delegates are object−oriented Delegates are classes, and while they wrap a call to a method they
still behave like objects. C++ function pointers are not classes and have no relationship at all with the
C++ object−oriented constructs.
• Delegates are type safe The .NET type system and the CLR enforce type safety of Delegates. To be
encapsulated by a Delegate, the method reference must precisely match the Delegate in number of
arguments, type of arguments, and return types. While the method names can differ, if the signatures
do not coincide, the Delegate cannot be instantiated. Traditional function pointers on the other hand
undergo no such safety checks. You can easily crash a system if you cast incorrectly. The power and
flexibility you have with function pointers thus carries a price, as C/C++ programmers have
discovered for years. Even the most experienced C++ programmers need to walk on eggshells when
working with function pointers. In short, Delegates do not let you "muck" with your code.
• Delegates are secure The CLR and type system ensure both the safety of Delegates and that they
behave according to the requirements of the security system. In other words, Delegates cannot gain
access to code they are not entitled to mix with. C++−style function pointers do not work within a
trust− based security system and cannot be adopted into a distributed software model like the .NET
Framework, in which everything revolves around secure programming.

492

You might also like