The constructor generic constraint is a slightly wierd one. The ECMA specification simply states that it: <\/p>\n
constrains [the type] to being a concrete reference type (i.e., not abstract) that has a public constructor taking no arguments (the default constructor), or to being a value type. There seems to be no reference within the spec to how you actually create an instance of a generic type with such a constraint. In non-generic methods, the normal way of creating an instance of a class is quite different to initializing an instance of a value type. For a reference type, you use and for value types, you need to use But, for a generic method, we need a consistent method that would work equally well for reference or value types.<\/p>\n To solve this problem the CLR designers could have chosen to create something similar to the However, this solution is much more heavyweight than This is where Going further: compiler enhancements<\/b><\/p>\n Although this method works perfectly well for solving the problem, the C# compiler goes one step further. If you decompile the C# version of the what you actually get is this (edited slightly for space & clarity): <\/p>\n What on earth is going on here? Looking closer, it’s actually quite a clever performance optimization around value types. So, lets dissect this code to see what it does.<\/p>\n The First, the stack transition for value types: <\/p>\n When the What about when Because For reference types, Next…<\/b><\/p>\n That concludes the initial premise of the Subterranean IL series; to cover the details of generic methods and generic code in IL. I’ve got a few other ideas about where to go next; however, if anyone has any itching questions, suggestions, or things you’ve always wondered about IL, do let me know.<\/p>\n","protected":false},"excerpt":{"rendered":" The constructor generic constraint is a slightly wierd one. The ECMA specification simply states that it: constrains [the type] to being a concrete reference type (i.e., not abstract) that has a public constructor taking no arguments (the default constructor), or to being a value type. There seems to be no reference within the spec to……<\/p>\n","protected":false},"author":186659,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[143538,2],"tags":[],"coauthors":[],"class_list":["post-3189","post","type-post","status-publish","format-standard","hentry","category-dotnet-development","category-blogs"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/3189","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/186659"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=3189"}],"version-history":[{"count":2,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/3189\/revisions"}],"predecessor-version":[{"id":41962,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/3189\/revisions\/41962"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=3189"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=3189"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=3189"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=3189"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}newobj<\/code>: <\/p>\nnewobj instance void IncrementableClass::.ctor()<\/pre>\n
initobj<\/code>: <\/p>\n.locals init ( valuetype IncrementableStruct s1 )\n\nldloca 0\ninitobj IncrementableStruct<\/pre>\n
Activator.CreateInstance<T><\/code><\/b><\/p>\nconstrained.<\/code> prefix; if T<\/code> is a value type, call initobj<\/code>, and if it is a reference type, call newobj instance void !!0::.ctor()<\/code>.<\/p>\nconstrained callvirt<\/code>. The newobj<\/code> call is encoded in the assembly using a simple reference to a row in a metadata table. This encoding is no longer valid for a call to !!0::.ctor()<\/code>, as different constructor methods occupy different rows in the metadata tables. Furthermore, constructors aren’t virtual, so we would have to somehow do a dynamic lookup to the correct method at runtime without using a MethodTable, something which is completely new to the CLR. Trying to do this in IL results in the following verification error: <\/p>\nnewobj instance void !!0::.ctor()\n\n[IL]: Error: Unable to resolve token.<\/pre>\n<\/p>\n
Activator.CreateInstance<T><\/code> comes in. We can call this method to return us a new T<\/code>, and make the whole issue Somebody Else’s Problem. CreateInstance<\/code> does all the dynamic method lookup for us, and returns us a new instance of the correct reference or value type (strangely enough, Activator.CreateInstance<T><\/code> does not itself have a .ctor<\/code> constraint on its generic parameter): <\/p>\n.method private static !!0 CreateInstance<.ctor T>() {\n call !!0 [mscorlib]System.Activator::CreateInstance<!!0>()\n ret\n}<\/pre>\nCreateInstance<\/code> method above: <\/p>\nprivate static T CreateInstance() where T : new() {\n return new T();\n}<\/pre>\n.method private static !!T CreateInstance<.ctor T>() {\n .locals init (\n [0] !!T CS$0$0000,\n [1] !!T CS$0$0001\n )\n \n DetectValueType:\n ldloca.s 0\n initobj !!T\n ldloc.0\n box !!T\n brfalse.s CreateInstance\n \n CreateValueType:\n ldloca.s 1\n initobj !!T\n ldloc.1\n ret\n \n CreateInstance:\n call !!0 [mscorlib]System.Activator::CreateInstance<T>()\n ret\n}<\/pre>\nCreateValueType<\/code> and CreateInstance<\/code> sections should be fairly self-explanatory; using initobj<\/code> for value types, and Activator.CreateInstance<\/code> for reference types. How does the DetectValueType<\/code> section work?<\/p>\nldloca.s 0 \/\/ &[!!T(uninitialized)]\ninitobj !!T \/\/\nldloc.0 \/\/ !!T\nbox !!T \/\/ O[!!T]\nbrfalse.s \/\/ branch not taken<\/pre>\n
brfalse.s<\/code> is hit, the top stack entry is a non-null reference to a boxed !!T<\/code>, so execution continues to to the CreateValueType<\/code> section.<\/p>\n!!T<\/code> is a reference type? Remember, the ‘default’ value of an object reference (type O<\/code>) is zero, or null. <\/p>\nldloca.s 0 \/\/ &[!!T(null)]\ninitobj !!T \/\/\nldloc.0 \/\/ null\nbox !!T \/\/ null\nbrfalse.s \/\/ branch taken<\/pre>\n
box<\/code> on a reference type is a no-op, the top of the stack at the brfalse.s<\/code> is null, and so the branch to CreateInstance<\/code> is taken.<\/p>\nActivator.CreateInstance<\/code> is called which does the full dynamic lookup using reflection. For value types, a simple initobj<\/code> is called, which is far faster, and also eliminates the unboxing that Activator.CreateInstance<\/code> has to perform for value types. However, this is strictly a performance optimization; Activator.CreateInstance<T><\/code> works for value types as well as reference types.<\/p>\n