468,161 Members | 1,918 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,161 developers. It's quick & easy.

Invoke vs. DynamicInvoke method in the delegate

I've just discovered DynamicInvoke methods while reading Jon's
threading article. And my question is how it's different from a
regular invoke method?

In this method:

/// <summary>
/// Invokes the wrapped delegate synchronously
/// </summary>
static void InvokeWrappedDelegate (Delegate d, object[] args)
{
d.DynamicInvoke(args);
}
Perhaps it parses arguments from object[] one by one, converting to
appropriate type, and passes them to delegate -- I am just guessing.
Nov 3 '08 #1
5 9149
On Sun, 02 Nov 2008 17:50:04 -0700, puzzlecracker <ir*********@gmail.com>
wrote:
I've just discovered DynamicInvoke methods while reading Jon's
threading article. And my question is how it's different from a
regular invoke method?

[...]

Perhaps it parses arguments from object[] one by one, converting to
appropriate type, and passes them to delegate -- I am just guessing.
I don't think it does. I believe that the arguments do need to match the
target method's declared types.

I admit, I have little first-hand information about DynamicInvoke(). But,
my understanding is that it's useful when you've got a delegate for which
the signature isn't known at compile time. It allows you to build the
argument list dynamically and pass it without matching a specific
signature.

Note that the Invoke() method is not part of the Delegate class per se,
but is generated for each delegate type by the compiler. It's done that
way so that the Invoke() method _does_ have a specific signature that
needs to be matched at compile-time.

In other words, DynamicInvoke() provides for late-bound, dynamic method
invocations, while the Invoke() method provides for statically typed,
early-bound invocations.

Pete
Nov 3 '08 #2
On Nov 2, 7:04 pm, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
wrote:
On Sun, 02 Nov 2008 17:50:04 -0700, puzzlecracker <ironsel2...@gmail.com>
wrote:
I've just discovered DynamicInvoke methods while reading Jon's
threading article. And my question is how it's different from a
regular invoke method?
[...]
Perhaps it parses arguments from object[] one by one, converting to
appropriate type, and passes them to delegate -- I am just guessing.

I don't think it does. I believe that the arguments do need to match the
target method's declared types.

I admit, I have little first-hand information about DynamicInvoke(). But,
my understanding is that it's useful when you've got a delegate for which
the signature isn't known at compile time. It allows you to build the
argument list dynamically and pass it without matching a specific
signature.

Note that the Invoke() method is not part of the Delegate class per se,
but is generated for each delegate type by the compiler. It's done that
way so that the Invoke() method _does_ have a specific signature that
needs to be matched at compile-time.
If it's generated by compiler then we cannot call it, which is not the
case. I thought it was predifined by the system each time delegate is
defined/instantiated.
Invoke becomes less clear to me.
In other words, DynamicInvoke() provides for late-bound, dynamic method
invocations, while the Invoke() method provides for statically typed,
early-bound invocations.
I see, thanks

Nov 3 '08 #3
Where is the article? Some of what Jon writes is probably just for
effect, cutting edge stuff to show his peers he's on top of things
(just guessing) with no practical immeadiate importance. I would
guess DynamicInvoke --whatever it is-- is one of those things they
might put in C#4.

RL

puzzlecracker wrote:
On Nov 2, 7:04 pm, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
wrote:
On Sun, 02 Nov 2008 17:50:04 -0700, puzzlecracker <ironsel2...@gmail.com>
wrote:
Nov 3 '08 #4
On Sun, 02 Nov 2008 18:30:38 -0700, puzzlecracker <ir*********@gmail.com>
wrote:
[...]
>Note that the Invoke() method is not part of the Delegate class per se,
but is generated for each delegate type by the compiler. It's done that
way so that the Invoke() method _does_ have a specific signature that
needs to be matched at compile-time.

If it's generated by compiler then we cannot call it, which is not the
case.
I'm not sure what you mean here. It's not speculation on my part that
Invoke() is generated by the compiler. It _is_ generated by the
compiler. You appear to be saying that code would not be able to call
Invoke() if that method weren't generated by the compiler, but that's not
true at all. Code can and does do just that.
I thought it was predifined by the system each time delegate is
defined/instantiated.
The "system" is the compiler. As far as the run-time is concerned, it's
just like any other type, at least in that by the time your code is
actually executing, you've got a well-defined type with statically defined
members (not to be confused with "static members", of course).
Invoke becomes less clear to me.
Hopefully the above clears things up a bit.

Pete
Nov 3 '08 #5
On Sun, 02 Nov 2008 18:13:20 -0700, Peter Duniho
<Np*********@nnowslpianmk.comwrote:
[...]
>If it's generated by compiler then we cannot call it, which is not the
case.

I'm not sure what you mean here. It's not speculation on my part that
Invoke() is generated by the compiler. It _is_ generated by the
compiler. You appear to be saying that code would not be able to call
Invoke() if that method weren't generated by the compiler, but that's
not true at all. Code can and does do just that.
Er, obviously that should read "if that method was generated by the
compiler". Sorry for the typo.
Nov 3 '08 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

13 posts views Thread by Christian Westerlund | last post: by
9 posts views Thread by Terry Olsen | last post: by
2 posts views Thread by dani kotlar | last post: by
6 posts views Thread by Dom | last post: by
reply views Thread by flyingchen | last post: by
1 post views Thread by gcdp | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.