If you come from a C++ programming background, you are most likely already familiar with C++’s template code bloat problem. Each template instantiation gets its own copy of the code (of course, compiler/linker can optimize by throwing away unused methods). The reason being that C++ template are more like C macro on steriods. I know this is a great simplification, but at the end of the day, it is pretty much a code expansion feature with type safety. This grants C++ some powerful capabilities that C# developers don’t have - like template specialization, or calling arbitary methods on a template class, or a whole different programming paradigm that’s known as template meta-programming. On the other hand, .NET generics require you to define what operations can be perform on T using constraints (otherwise you are limited to a small set of operations such as casts, assignments, etc). However, this does give .NET a unique advantage - it can do a better job at code sharing.
I recently had some really interesting discussion with a .NET typesystem expert in the team, and during the conversation he had pointed out an interesting aspect of .NET value type boxing when using constraints. Intrigued by that discussion, I decided to take a further look.
If you’ve been following .NET Core development you’ve probably already heard about .NET Standard 2.0. We are bringing back a lot of APIs from desktop to .NET Core to make migrating existing apps easier. If you’d like to read more about what is netstandard, you can refer to this faq. In this post I’m going to show you how to dogfood (read: try out the bleeding edge new stuff) the latest .NET Core 2.0 which has the latest API changes in .NET Standard 2.0.
I’ve spent a non-trival part of my career adding Windows Runtime support to .NET framework and .NET native, and I often get people asking me what is Windows Runtime and there is a lot of confusion around it. The bad naming certainly doesn’t help in this case. I’m going to write a series blog post so that I can point people to. :)
When interop with native code using C# p/invokes, some time you need to create unions in C#. They are represented by structs with
[StructLayout(LayoutKind.Explicit)] attribute and the fields annotated with
[FieldOffset(0)] specifying their offset. It looks pretty straight-forward, but in practice this can be very deceiving. In this article, I’ll talk about two important rules when using unions.
CoreCLR is the runtime that runs your .NET Core application, just like the ‘classic’ .NET in your machine, except it’s much smaller and requires no installation. This makes it ideal for embedding .NET code as part of your application without additional dependency, and you completely are in control of the version of CoreCLR that you are running.
In my previous blog I talked about how to call to C functions directly using syscall module, without using Cgo. We can expand this idea a bit further - to call COM objects in Go. As a simple example, let’s see if we can call IMalloc interface implemented in Windows.
I’ve recently started learning GO and given that I’ve spent majority of my career in interop between runtimes and languages, I’m naturally curious on how you can interop between GO and other languages. It is most important to have the two functionality below:
- retrieve a native function pointer
- call the native function pointer with arguments and receive values back