As always, one question at StackOverflow attracted my attention and made me program all the night. The question was actually about a way to refer to a predefined object in a dynamically emitted method in a dynamic assembly. That is actually quite an easy task, provided you aren't going to save the assembly and use it later in a different program. In this case, simply use some way to refer to the object using a number (add it to a list, or use a GCHandle) and there's nothing easier than emitting an integer in CIL.
If you want to save the assembly, this approach obviously will not work, as the object will be lost when you quit the runtime. In this case, you'd have to find an optimal way to serialize the desired object, either directly calling its constructor in method, or use a serializer and put the result in the assembly resource space.
However, for some strange reason, I didn't immediately think about those two ways, probably because it was late night. Instead, I thought about compiled lambdas in Linq.Expressions and how closures work there (mainly Expression.Constant). Behind all that emitting, it's actually quite simple - if you know how delegates work. Someone coming over from the land of C will think about delegates as wrappers for function pointers, but it's more than that. You can bind a function pointer to a specific target object, which is then internally used as the first argument to the method (you can actually even bind static methods to target objects, and they behave as expected).
LINQ Expressions work the same way - the compiled lambda is dynamically emitted, and non-primitive constants are placed in a special container, which is then used as the target object of the created delegate. The compiled method would then access the container as easily as using this in an instance method. Provided I wouldn't have to save the assembly, what if I were to bind the desired object to a delegate and then call that delegate in the dynamic assembly?
The immediate problem here is obvious - the delegate has a target object, and I still have no way (ignore the first paragraph) to refer to it from inside the dynamic method. What I would want is a way to generate a piece of code that somehow stores the delegate and its target object, and would allow me to call it as a raw function pointer. Hmm, is there something in .NET that does that?
December 23, 2016
Invoking a delegate from inside a dynamic method
July 24, 2016
C++/CLI type system as seen from .NET and CIL
For some time now, I have delved, out of necessity, into C++ and all its quirks and secrets. One thing that has always fascinated me in C++ is its marvelously complex type system. In C#, you can mostly just work with arrays, pointers are possible but not recommended, and also generics. C++ has loads of declarators – arrays with fixed size, pointers, references, and this all can be combined with anything else and also qualifiers – mostly const and volatile. These two keywords also exist in C#, but they have vastly different meaning.
Now you may be surprised or not, but all these constructions are actually accurately representable in Common Intermediate Language (CIL for short), the language that separates all .NET languages from native code. Though C# doesn't show the full potential of its type system (however, the newest drafts have quite appealing suggestions, like ref returns), in CIL, the type system is as rich as C++'s, maybe even richer.
C++/CLI is a beautiful and well-designed combination of C++ and .NET, and shall serve as an example of how its types are translated into CIL. If you are not familiar with C++ at all, don't worry, I'll be easy on you. The following descriptions will be mainly from the C# perspective; all in all, that's from whence I come.
Let's start with an overview of what types we'll have to consider: