Datatype of Methods

Question

Question

How does a delegate store a reference to a function? The source code appears to refer to it as an Object, and the manner in which it invokes the method seems redacted from the source code. Can anyone explain how C# is handling this?

---

Original Post

It seems I'm constantly fighting the abstractions C# imposes on its programmers. One that's been irking me is the obfuscation of Functions/Methods. As I understand it, all methods are in fact anonymous methods assigned to properties of a class. This is the reason why no function is prefixed by a datatype. For example...

void foo() { ... }

... would be written in Javascript as...

Function foo = function():void { ... };

In my experience, Anonymous functions are typically bad form, but here it's replete throughout the language standard. Because you cannot define a function with its datatype (and apparently the implication/handling is assumed by the compiler), how does one store a reference to a method if the type is never declared?

I'm trying very hard to avoid Delegates and its variants (Action & Func), both because...

1. it is another abstraction from what's actually happening
2. the unnecessary overhead required to instantiate these classes (which in turn carry their own pointers to the methods being called).

Looking at the source code for the Delegate.cs, it appears to refer to the reference of a function as simply Object (see lines 23-25).

---

If these really are objects, how are we calling them? According to the delegate.cs trail, it dead-ends on the following path:

Delegate.cs:DynamicInvoke() > DynamicInvokeImpl() > methodinfo.cs:UnsafeInvoke() > UnsafeInvokeInternal() > RuntimeMethodHandle.InvokeMethod() > runtimehandles.cs:InvokeMethod()

internal extern static object InvokeMethod(object target, object[] arguments, Signature sig, bool constructor);

This really doesn't explain how its invoked if indeed the method is an object. It feels as though this is not code at all, and the actual code called has been redacted from source repository.

Your help is appreciated.

---

Response to Previous Comments

@Amy: I gave an example immediately after that statement to explain what I meant. If a function were prefixed by a datatype, you could write a true anonymous function, and store it as a property to an Object such as:

private Dictionary<string, Function> ops = new Dictionary<string, Function> {
    {"foo", int (int a, int b) { return a + b } }
};

As it stands, C# doesn't allow you to write true anonymous functions, and walls that functionality off behind Delegates and Lambda expressions.

@500 Internal server error: I already explained what I was trying to do. I even bolded it. You assume there's any ulterior motive here; I'm simply trying to understand how C# stores a reference to a method. I even provided links to the source code so that others could read the code for themselves and help answer the question.

@Dialecticus: Obviously if I already found the typical answer on Google, the only other place to find the answer I'm looking for would be here. I realize this is outside the knowledge of most C# developers, and that's why I've provided the source code links. You don't have to reply if you don't know the answer.

Answer 1

While I'm not fully understanding your insights about "true anonymous functions", "not prefixed by a data type" etc, I can explain you how applications written in C# call methods.

First of all, there is no such a thing "function" in C#. Each and every executable entity in C# is in fact a method, that means, it belongs to a class. Even if you define lambdas or anonymous functions like this:

collection.Where(item => item > 0);

the C# compiler creates a compiler-generated class behind the scenes and puts the lambda body return item > 0 into a compiler-generated method.

So assuming you have this code:

class Example
{
    public static void StaticMethod() { }
    public void InstanceMethod() { }
    public Action Property { get; } = () => { };
}

static class Program
{
    static void Main()
    {
        Example.StaticMethod();
        var ex = new Example();
        ex.InstanceMethod();
        ex.Property();
    }
}

The C# compiler will create an IL code out of that. The IL code is not executable right away, it needs to be run in a virtual machine.

The IL code will contain a class Example with two methods (actually, four - a default constructor and the property getter method will be automatically generated) and a compiler-generated class containing a method whose body is the body of the lambda expression.

The IL code of Main will look like this (simplified):

call void Example::StaticMethod()
newobj instance void Example::.ctor()
callvirt instance void Example::InstanceMethod()
callvirt instance class [mscorlib]System.Action Example::get_Prop()
callvirt instance void [mscorlib]System.Action::Invoke()

Notice those call and callvirt instructions: these are method calls.

To actually execute the called methods, their IL code needs to be compiled into machine code (CPU instructions). This occurs in the virtual machine called .NET Runtime. There are several of them like .NET Framework, .NET Core, Mono etc.

A .NET Runtime contains a JIT (just-in-time) compiler. It converts the IL code to the actually executable code during the execution of your program.

When the .NET Runtime first encounters the IL code "call method StaticMethod from class Example", it first looks in the internal cache of already compiled methods. When there are no matches (which means this is the first call of that method), the Runtime asks the JIT compiler to create such a compiled-and-ready-to-run method using the IL code. The IL code is converted into a sequence of CPU operations and stored in the process' memory. A pointer to that compiled code is stored in the cache for future reuse.

This all will happen behind the call or callvirt IL instructions (again, simplified).

Once this happened, the Runtime is ready to execute the method. The CPU gets the compiled code's first operation address as the next operation to execute and goes on until the code returns. Then, the Runtime takes over again and proceeds with next IL instructions.

The DynamicInvoke method of the delegates does the same thing: it instructs the Runtime to call a method (after some additional arguments checks etc). The "dead end" you mention RuntimeMethodHandle.InvokeMethod is an intrinsic call to the Runtime directly. The parameters of this method are:

• object target - the object on which the delegate invokes the instance method (this parameter).
• object[] arguments - the arguments to pass to the method.
• Signature sig - the actual method to call, Signature is an internal class that provides the connection between the managed IL code and native executable code.
• bool constructor - true if this is a constructor call.

So in summary, methods are not represented as objects in C# (while you of course can have a delegate instance that is an object, but it doesn't represent the executable method, it rather provides an invokable reference to it).

Methods are called by the Runtime, the JIT compiler makes the methods executable.

You cannot define a global "function" outside of classes in C#. You could get a direct native pointer to the compiled (jitted) method code and probably even call it manually by directly manipulating own process' memory. But why?

Answer 2

You clearly misunderstand main differences between script languages, C/C++ and C#.

I guess the main difficulty is that there is no such thing as a function in C#. At all. C#7 introduced the new feature "a local function", but that is not what a function in JS is. All pieces of code are methods. That name is intentionally different from function or a procedure to emphasize the fact that all executable code in C# belongs to a class.

Anonymous methods and lambdas are just a syntax sugar. A compiler will generate a real method in the same (or a nested) class, where the method with anonymous method declaration belongs to.

This simple article explains it. You can take the examples, compile them and check the generated IL code yourself.

So all the methods (anonymous or not) do belong to a class. It's impossible to answer your updated question, besides saying It does not store a reference to a function, as there is no such thing in C#.

How does one store a reference to a method?

Depending on what you mean by reference, it can be either

1. An instance of MethodInfo class, used to reference reflection information for a method,
2. RuntimeMethodHandle (obtainable via RuntimeMethodInfo.MethodHandle) stores a real memory pointer to a JITed method code
3. A delegate, that is very different from just a memory pointer, but logically could be used to "pass a method reference to another method" .

I believe you are looking for the MethodInfo option, it has a MethodInfo.Invoke method which is very much alike Function..apply function in JS. You have already seen in the Delegate source code how that class is used.

If by "reference" you mean the C-style function pointer, it is in RuntimeMethodHandle struct. You should never use it without solid understanding how a particular .Net platform implementation and a C# compiler work.

Hopefully it clarifies things a bit.