Been looking around the net and can't find any articles about how value types are actually implemented.
For instance, an Int32 is a struct and it's direct pa开发者_如何学Gorent is System.ValueType and that's ultimate parent is System.Object. Object is a class - I imagine ValueType is a class?
What's the class hierarchy? What part does the CLR have to play? At what stage and how does the CLR know to allocate value types to the stack? (FYI, I am aware that value types are stored where they are declared).
Smoke and mirrors is the best way to describe it. I'll try better. Value types don't support inheritance and cannot have virtual methods. But yet, the int type has the ToString() and GetHashCode() methods, both virtual methods. It inherits them from System.Object.
This magic comes about from a boxing conversion. There are dedicated IL opcodes that perform it, OpCodes.Box and OpCodes.Constrained. That turns a value type into an object, one that stores the value of the original value type. It goes the other way around too, unboxing converts an object back to a value type.
If you have a good .NET compiler, like the C# one, you never explicitly invoke the conversion yourself. The compiler can figure out from the language syntax when such a conversion is required and emits the required IL code.
The System.Int32 type is a helper type that the compiler has special knowledge of. It is useful for its methods only, you never explicitly create an instance of it. The compiler calls those methods directly when it knows that you are calling a method of the int "class".
All of this works together to create the illusion that int derives from System.Object (through System.ValueType). Using the principle of "if it looks, swims and quacks like a duck, it's a duck".
Value types are handled specially by the various language compilers and by the CLR. Quite simply, the CLR knows that everything that derives from ValueType is to be passed around by value and that local ValueType variables live on the stack.
I don't know how much more it is possible to say about value types without wandering into the realms of "implementation-defined".
The class hierarchy is a bit artificial in this case. Whether a type is a reference or a value type is stored directly in the type metadata, so the CLR doesn't need to see whether or not it's derived from System.ValueType. But System.ValueType does help a bit - it implements value equility checking and GetHashCode().
The CLR allocates space on the stack for any local variables of a type that is marked as ".class value" in its metadata. When exactly that happens depends on whether the code is optimized or not. If it's not optimized then it happens at the declaration to aid debugging. If it is optimized then probably as late as possible, but it's up to the implementation.
I'm not sure what else to say, since your question is quite broad as it's currently worded.
精彩评论