Hi,
Delegates allow you to specify at run time the method to be invoked.??

What does the above line mean?? Everytime, I have seen a .NET code related
to delegates, we specify the method to be invoked, ie., while coiding we
have to specify the method. Then what is meant by runtime here ??

Can anyone explain the true benefits of using a delegate???

Hello, Ginny!

G> Hi,
G> Delegates allow you to specify at run time the method to be
G> invoked.??

G> What does the above line mean?? Everytime, I have seen a .NET code
G> related
G> to delegates, we specify the method to be invoked, ie., while coiding
G> we
G> have to specify the method. Then what is meant by runtime here ??

G> Can anyone explain the true benefits of using a delegate???

In runtime - means that you can change application behavior without
rebuilding it.

In case with delegates it the same as assiging variables in the runtime ( when app is up
and running ).

Say we have simple delegate

delegate void TestDelegate(string message);

And we have to different methods that have different behavior;

void Method1(string message)
{
    //diaplayes message via MessageBox.Show(...);
}

void Method2(string message)
{
    //Sends the message to application event log
}

Now in the runtime user sets some flag, and we changes the behavior of the app in the runtime

TestDelegate ourDelegate;    //we declare delegate
if ( flag )
    ourDelegate = Method1;
else
    ourDelegate = Method2;

ourDelegate("Show the message");

Code above shows the runtime usage of delegates.
There are more complex delegates applications out there

have a look at ( http://ebersys.blogspot.com/2006/08/arrays-of-methods-in-c.html )

Hi, Thanks for your reply.

1. Well, this could have simply be done by calling the method directly. Why
are we going round robin and calling the method through the delegate.
2. Delegates does help in some manner at least but not the way it has been
exaggerated. It simply is a pointer at the end of the day.

Show quoteHide quote( when app is up
Show quoteHide quoteapp in the runtime
http://ebersys.blogspot.com/2006/08/arrays-of-methods-in-c.html )
Show quoteHide quote

Hello, Ginny!

G> 1. Well, this could have simply be done by calling the method
G> directly. Why
G> are we going round robin and calling the method through the delegate.

To obtain generic behavior

G> 2. Delegates does help in some manner at least but not the way it
G> has
G> been
G> exaggerated. It simply is a pointer at the end of the day.


Yes, it is a type-safe function pointer. And it has to be understood like this.

And function pointers are used in various scenarios:
- factory methods
- different kinds of callbacks
and etc, and etc

Show quoteHide quoteG> ( when app is up
Show quoteHide quoteG> app in the runtime

G> http://ebersys.blogspot.com/2006/08/arrays-of-methods-in-c.html )

Imagine in the case of the example given that the check for which delegate
to use is done once and the results stored somewhere else, to be used
multiple time later.  That would be more similar to the usual use of a
delegate.

You are right that if the check is immediately followed by the use, one
could just call the methods directly.  But the situations in which a
delegate is actually used aren't actually so simple.  I suspect that the
example Vadym gave was just oversimplified in an attempt at clarity.  It
doesn't mean that delegates aren't useful.

One of the most common ways a delegate is used in .NET is for event
handling.  Even at compile time, a .NET class may not know what method will
be called in response to an event being handled, and/or more than one method
might need to be called.  Using delegates allows the code to resolve the
called method at runtime, as well as allows the code to maintain a list of
methods to be called at runtime.

There are lots of situations in which delegates are useful, and for the most
part they are similar to the reasons that one would use a function pointer
in C.

What do you mean by "the way it has been exaggerated"?  I haven't seen any
documentation that exaggerates the use of delegates.

Also, a delegate is not "a pointer at the end of the day".  I'd agree that
the distinction is small, but there are no pointers in safe .NET code.  As
with practically everything else, a delegate is an object that can be
referenced via the usual .NET syntax.  It is more than just a pointer.

One key difference is that the type of the delegate is attached to the
delegate.  In C, if you get a function pointer, the type for that pointer is
determined at compile time by the type of whatever variables in which it is
stored.  If you cast a C function pointer to a void* and then back to a
function pointer, there is no way at run time to ensure that the new
function pointer type matches the actual function in question.  In .NET, all
of this information is persistent and the CLR can do the necessary checks
even at runtime to ensure correct use of a delegate.

As with everything else in .NET, a delegate is "type safe".

It's true that delegates are used in .NET in very much the same way that
function pointers are used in C.  But they aren't exactly the same.

Pete

Quite so.  In fact, a .NET delegate is more like a list of structures, each
of which contains a pointer to an object and a member function pointer.
Invoking the delegate invokes each pair of object pointer/member function
pointer in turn.  Static functions are represented by a pair having a null
object pointer.

So, in C++ terms, something like

std::vector<std::pair<T*, Tr T::*(T1,T2,T3,...)> >

But unlike C++ member function pointers, a delegate is not restricted to
point only to functions that are members of a particular class.  Rather, a
delegate can refer to any function with a compatible signature, regardless
of the class (in that regard, they're more like C function pointers than C++
member function pointers).  In contrast to the two distinctly different
function pointer types in C++ (ordinary and member), a .NET delegate can
refer to any function with a compatible signature, regardles of whether it's
static or not, and regardless of what class it's a member of.

-cd

Ginny wrote:
Let's think about Form class in .NET framework.
Say, you define an new Form in your application and you create an Load
event handler. What will happen in run-time it's that Microsoft's
System.Windows.Forms.Form class will call your method.

And, MS couldn't know how you will name your methods, did they ?
So, this demonstrates that delegates are not equivalent with calling
methods directly in your code.

Regards,
Petar Repac

There are a couple of ways of changing the delegate at runtime. First, is
through a configuration file where you add handlers based on the
configuration. This may not seem runtime, as you have probably tested prior
to production compile, but it is technically runtime binding. You can also
reflect and add the delegate.

Benefits of a delegate? The primary one is to be able to raise events in one
class and handle them in another class. Yes, this is an oversimplification,
but i is an easy concept to grasp.

Show quoteHide quote

Ginny wrote:
I understand delegates (and use them) as the equivalent of old C
function pointer prototypes. If in an old C program you wanted to use
function pointers to call routines which were specified at run-time, you
would need to carefully define the prototype of the function to be
called. So it is true of delegates: if you want to call an Event, you
have to know what arguments to pass to the event, which in turn are
defined by the Event delegate.

Hope this helps.

Neil B

Ginny <techni***@peoplewareindia.com> wrote:
See http://www.pobox.com/~skeet/csharp/events.html

Data Feed architecture
ObjectDisposedException if USBtoSerial Port is unplugged
String -> StringBuilder Optimization
regex expression
Very large arrays and .NET classes