dotnet clr: Does anyone know what is behind the runtime managed ".ctor" and "Invoke"
methods of a delegate type?

What is performed in these methods whose bodies are provided by the runtime?

Any idea?

Dear Robert,

Thankx for the answer.

[quoted text, click to view]

I would be interested more in detail. What do you mean by "(optimized) call
of the delegate"?
What exactly is preparing the constructor?

many thanks again!

[quoted text, click to view]

I'm just guessing:

- "Invoke" does an "early-bind" (optimized) call of the delegate
- the constructor is preparing something for "Invoke"

bye

Hi Robert,

[quoted text, click to view]

it's "cannot" :))

[quoted text, click to view]

exactly. this is the point of my question :) I want to know what is inside
these blackboxes (runtime managed). For example, I think that the .cctor sets
the two private fields "_target" and "_methodPtr". What else it does?

How it's the invocation with Invoke optimized?

Thank you Robert.

[quoted text, click to view]

I want to (formally) model these delegates methods.

Mattias,

[quoted text, click to view]

You are definitely right. Of course it violates the Spec.

Do you have any idea what is behind these runtime managed methods of a
delegate class?

Hi George,

[quoted text, click to view]

You're welcome!

[quoted text, click to view]

I'm *still* guessing ;-)

Delegates are (special) classes that derive from MulticastDelegate.
When you define a new delegate type you don't need (or even cannot?)
to provide an implementation because the runtime already provides
a common optimized implementation for all delegate types. That's why
all methods are to be declared "runtime managed" with an empty body.

"runtime managed" methods are black boxes. you don't need to
know what happens inside them, even when you're programming
lowlevel IL.

bye

Hi George,

I took a look an the IL of the following code:

delegate void MyEventHandler(object sender, EventArgs e);

The compiler generates a class derived from MulticastDelagate
consisting of these "runtime managed" (thus empty) methods:

..ctor
Invoke
BeginInvoke
EndInvoke

However, you *can* provide an CIL implementation too.
I changed "runtime managed" to "cil managed" and
it works:

.method public hidebysig virtual instance void
Invoke(object sender,
class [mscorlib]System.EventArgs e) cil managed
{
ldstr "test"
call void [mscorlib]System.Console::WriteLine(string)
ret
}

So if you don't like the "runtime managed" black boxes
you still can roll your own delegate implementation, though
probably a bad idea.

bye

Hi George,

[quoted text, click to view]

Ok :-)

[quoted text, click to view]

Hmm, Reflector is definitely able to disassemble the System.Delegate
..ctor. No magic inside apart from the InternalCalls :-)

You may take a look at Rotor (the shared source .NET from MS)
or at Mono (OpenSource).

Out of curiosity, what are you trying to achieve?

bye

Robert,

[quoted text, click to view]

But is the result verifiable (test with PEVerify)? It certainly
violates section 13.6 in partition II of the ECMA specification.



Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com

George,

[quoted text, click to view]

Well that's implementation dependant and can vary from one CLI
implementation to another. For the CLR, see comdelegate.cpp/.h at

http://sharedsourcecli.sscli.net/source/browse/sharedsourcecli/clr/src/vm/

You can probably find similar code in the Mono source.



Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com

Hi Mattias,

[quoted text, click to view]

No, it doesn't pass the tests. Mono completely ignores the hack.

bye