ValueType vs Reference
-
There is an ongoing "discussion" among my colleagues about exactly how a ValueType is stored internally. We are looking for some other views. If a ValueType is derived from System.Object, does it have a vtable or is it stored in raw form until boxed. In other words, is an System.Int32 stored on the stack as a 4 byte integer or does it have a vtable therby making it larger than 4 bytes?
This article[^] should be intersting for you. Robert
-
This article[^] should be intersting for you. Robert
The first sentence of the article reads "A Value Type instance on stack without any Method Table ..." Does that mean an System.Int32 is stored on the stack in just 4 bytes (sounds like it to me)? If so, how does System.ValueType's derivation from System.Object (in which it overides the System.Object methods) avoid a "Method Table?" Assuming the compiler "changes" a System.Int32 to its 4 byte raw form for storage on the stack, what is the purpose of deriving System.ValueType from System.Object? Thanks for the article...
-
The first sentence of the article reads "A Value Type instance on stack without any Method Table ..." Does that mean an System.Int32 is stored on the stack in just 4 bytes (sounds like it to me)? If so, how does System.ValueType's derivation from System.Object (in which it overides the System.Object methods) avoid a "Method Table?" Assuming the compiler "changes" a System.Int32 to its 4 byte raw form for storage on the stack, what is the purpose of deriving System.ValueType from System.Object? Thanks for the article...
Yes, an integer will only take 4 bytes. If the "Method table" is needed it will be generated by the CLR on demand. Google boxing and C# for details. This design allows the lower memryconsumption and faster performance of native types, while still allowing object oriented programming with the native types. The "price" you pay is a performance hit when boxing/unboxing.
-
Yes, an integer will only take 4 bytes. If the "Method table" is needed it will be generated by the CLR on demand. Google boxing and C# for details. This design allows the lower memryconsumption and faster performance of native types, while still allowing object oriented programming with the native types. The "price" you pay is a performance hit when boxing/unboxing.
-
I understand how and why boxing is used... The question remains: If a System.Int32 occupies only 4 bytes on the stack, what is the purpose of deriving System.ValueType from System.Object? Thanks for your reply...
If System.ValueType did not derive from System.Object, how would you make a collection like this one: System.Collections.Generic.List which can contain objects of any time - including value types. If System.ValueType did not derive from System.Object, you would basically need an interface to provide the standard methods (ToString, Hash value, etc)... but to be accessed from an interface the value type would still need to be boxed and now you also need to cast anything derived from System.Object to the interface constantly. So basically nothing was simplified but complexity was added. Just out of curiosity, what do you think the benefit of NOT deriving from System.Object would be?
-
If System.ValueType did not derive from System.Object, how would you make a collection like this one: System.Collections.Generic.List which can contain objects of any time - including value types. If System.ValueType did not derive from System.Object, you would basically need an interface to provide the standard methods (ToString, Hash value, etc)... but to be accessed from an interface the value type would still need to be boxed and now you also need to cast anything derived from System.Object to the interface constantly. So basically nothing was simplified but complexity was added. Just out of curiosity, what do you think the benefit of NOT deriving from System.Object would be?
Your explanation implies that System.ValueType has more information than just the raw memory needed to store the data (an 4 byte integer in my previous examples). I'll try to restate my original question, again using the ValueType System.Int32 as an example: Does an instance of System.Int32 occupy only 4 bytes in memory when it is allocated on the stack? If so, what is the purpose of deriving System.ValueType from System.Object if it does not carry any information from System.Object?
-
Your explanation implies that System.ValueType has more information than just the raw memory needed to store the data (an 4 byte integer in my previous examples). I'll try to restate my original question, again using the ValueType System.Int32 as an example: Does an instance of System.Int32 occupy only 4 bytes in memory when it is allocated on the stack? If so, what is the purpose of deriving System.ValueType from System.Object if it does not carry any information from System.Object?
Yes an instance of System.Int32 occupies exactly 4 bytes in memory when it is allocated on the stack. Yes an instance of System.Int32 is also a System.Object and if the CLR needs its object behavior, the compiler will have provided the necessary code to make it act as an object, but that does not change the data foot print. Example:
int a=12;
string s=a.ToString();the ToString() method applies to "object" a, the compiler will allocate a 4B integer on stack and generate code that calls System.Int32.ToString(). :)
Luc Pattyn [Forum Guidelines] [My Articles]
this months tips: - use PRE tags to preserve formatting when showing multi-line code snippets - before you ask a question here, search CodeProject, then Google
-
Yes an instance of System.Int32 occupies exactly 4 bytes in memory when it is allocated on the stack. Yes an instance of System.Int32 is also a System.Object and if the CLR needs its object behavior, the compiler will have provided the necessary code to make it act as an object, but that does not change the data foot print. Example:
int a=12;
string s=a.ToString();the ToString() method applies to "object" a, the compiler will allocate a 4B integer on stack and generate code that calls System.Int32.ToString(). :)
Luc Pattyn [Forum Guidelines] [My Articles]
this months tips: - use PRE tags to preserve formatting when showing multi-line code snippets - before you ask a question here, search CodeProject, then Google
-
Bravo! That is the best explanation yet. This is exactly what MOST of my colleagues believe. The devils advocate of the group maintains that: int a=12; // is not a ValueType until string s = a.ToString() // is called Thanks everybody for your input.
Well, most of your colleagues are right. It suffices to compile some code and look at the generated MSIL (e.g. with ILDASM) to observe an int is simply an int, and some class methods get called when appropriate. :)
Luc Pattyn [Forum Guidelines] [My Articles]
this months tips: - use PRE tags to preserve formatting when showing multi-line code snippets - before you ask a question here, search CodeProject, then Google
-
Bravo! That is the best explanation yet. This is exactly what MOST of my colleagues believe. The devils advocate of the group maintains that: int a=12; // is not a ValueType until string s = a.ToString() // is called Thanks everybody for your input.
I am sorry my answer: "Yes, an integer will only take 4 bytes." could leave you in doubt how much memory an integer takes, though I have no idea what so ever how it could be written clearer. And no, my explanation does obviously not imply that more data is stored than the 4 bytes. I do not know what you mean with "more information available" - yes, obviously it has. Every single object ever created has more information available than the bytes it takes up in memory (as it can easily access the information for the class itself). Or maybe you are referring to the information built into the CLR allowing it to do the boxing/unboxing - sure there is information available for that as well, but obviously per class, not per object, so it does not affect the amount of bytes each object use. With regards to: int a=12; // is not a ValueType until string s = a.ToString() // is called it probably goes on details in the CLR. "a" is not boxed before the a.ToString call, but at any time "a is ValueType" would return true, and at any time it can be used as a ValueTime. Hence I would consider it a ValueType no matter how it happens to be represented in memory, but I can see the other side of the argument as well - it all comes down to seeing it from the level of C# or from the level of the CLR implementation.
-
Bravo! That is the best explanation yet. This is exactly what MOST of my colleagues believe. The devils advocate of the group maintains that: int a=12; // is not a ValueType until string s = a.ToString() // is called Thanks everybody for your input.
Also, this is valid: string s = 12.ToString();
"We make a living by what we get, we make a life by what we give." --Winston Churchill
-
Also, this is valid: string s = 12.ToString();
"We make a living by what we get, we make a life by what we give." --Winston Churchill
And VS will show "Int32" tooltip when you hover over that 12 :)
[My Blog]
"Visual studio desperately needs some performance improvements. It is sometimes almost as slow as eclipse." - Rüdiger Klaehn
"Real men use mspaint for writing code and notepad for designing graphics." - Anna-Jayne Metcalfe