[C#] Call functions without having to declare delegates

[bigtimt]

Below is an example of using the intermediate language generator to call functions without having to declare or register a delegate. At the current moment it only supports x86, but that is all i need it for, modify it if you want x64 support.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Reflection;
using System.Reflection.Emit;
using System.Runtime.InteropServices;

namespace Phoenix
{
    public static class Functions
    {
        public static retType CallFunction<retType>(IntPtr pFunction, CallingConvention CallingConvention, params Object[] args)
        {
            Type ReturnType = typeof(retType);
            Type[] ParamTypes = (from arg in args
                                 select arg.GetType()).ToArray();

            DynamicMethod dm = new DynamicMethod("DynamicInvoke", ReturnType, ParamTypes, typeof(Object));
            ILGenerator il = dm.GetILGenerator();

            for (Int32 i = 0; i < args.Length; i++)
                il.Emit(OpCodes.Ldarg, i);

            il.Emit(OpCodes.Ldc_I4, pFunction.ToInt32());
            il.EmitCalli(OpCodes.Calli, CallingConvention, ReturnType, ParamTypes);
            il.Emit(OpCodes.Ret);

            return (retType)dm.Invoke(null, args);
        }

        public static void CallFunction(IntPtr pFunction, CallingConvention CallingConvention, params Object[] args)
        {
            CallFunction<Int32>(pFunction, CallingConvention, args);
        }
    }
}

Example Usage:

CallFunction((IntPtr)Offsets.LuaDoString, "DoEmote('dance')", "LuaFilename", 0)

[Apoc]

The one major drawback to doing this, is that reflection is slow (especially Reflection.Emit).

The performance difference between the two is a fairly large difference. Not to mention; you're forced into proper type-safe functions. (And you can do proper marshaling of the function parameters and return values if you want. Not to mention, ref/out params)

Nice work though.

[Robske]

Removes the hassle of setting up a delegate if you want to test or debug something fast I suppose.

Thanks

[bigtimt]

The one major drawback to doing this, is that reflection is slow (especially Reflection.Emit).

The performance difference between the two is a fairly large difference. Not to mention; you're forced into proper type-safe functions. (And you can do proper marshaling of the function parameters and return values if you want. Not to mention, ref/out params)

Nice work though.

Performance difference is only ~25x slower than a regular call, that's not that much :P

[XTZGZoReX]

The one major drawback to doing this, is that reflection is slow (especially Reflection.Emit).

That's very relative.. If you cache the generated IL and call it directly instead of re-generating it all the time, you could actually achieve quite the performance gain. This is simply because the C# compiler doesn't really optimize that well (due to the strict definition of many language aspects).

[bigtimt]

well if you are going to cache the IL it would just be quicker to use a delegate :P

[XTZGZoReX]

well if you are going to cache the IL it would just be quicker to use a delegate :P

Again, depends. If we're talking performance, you can gain a lot of such by generating and caching your own IL rather than using delegates (and perhaps anonymous methods). Granted, you'll need to understand what you're doing.

[bigtimt]

I'm not talking about the speed of the code, was talking about speed of development

[XTZGZoReX]

I'm not talking about the speed of the code, was talking about speed of development

I was commenting on Apoc's post.

[bigtimt]

gg (filler.)

[Apoc]

A delegate would be faster either way.

The way I do delegates (with the Marshal.GetDelegateForFunctionPointer) literally leaves me with a delegate pointing at a func ptr.

This Reflection.Emit code uses a mock-delegate, and DynamicInvoke, (which if you read MSDN, is stupidly slow, but required at times).

You should do the profiling for yourself.

[bigtimt]

It's not actually Microsoft's dynamic invoke, i just named it that because it is sort of the same thing. And I did do some profiling and delegates came out about ~25 times faster than using the above method, I just figured it was a cool piece of code :P

[Apoc]

It's not actually Microsoft's dynamic invoke, i just named it that because it is sort of the same thing. And I did do some profiling and delegates came out about ~25 times faster than using the above method, I just figured it was a cool piece of code :P

My point is proven! :P

Your code is incredibly useful when you want to quickly toss together some stuff for messing around, and testing stuff. Definitely not something you wanna use in a to-be-released app.