Re: Value Types and Reference Types
- From: "Jon Slaughter" <Jon_Slaughter@xxxxxxxxxxx>
- Date: Tue, 01 Apr 2008 10:57:17 GMT
"Dom" <dolivastro@xxxxxxxxx> wrote in message
news:93ea4342-9661-452c-824f-d953451aacb5@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Let me explain my mental image, and then tell me where I've gone
wrong.
There is a stack and a heap. A reference type sits on the heap, and
its address sits on the stack. When you pass it to a method, you pass
the contents of the stack, which is the same as passing the address of
the object.
A value type just sits on the stack. When you pass it to a method,
you pass the contents of the stack, just as before. Only now the
method knows not to "dereference" it.
Now, here's the problem. I had a method that received an integer, and
I wanted to modify it so it could also receive a DateTime. I could
have overloaded the method, but because I am stuck in VB-think, i just
changed the argument from integer to object, assuming it worked like
VB's "Any". And it worked. But according to my mental image, the
method should have taken the value sent and tried to look it up on the
heap, and then fail. Or the compiler should have complained about a
mismatch.
All types derive from System.Object. Value types are special types that can
"fit" on the stack. The compiler basically has a list of types that are
special and will stick them on the stack instead of the heap when used.
(struct is a general type that gets this priviledge but is made up of the
more simple types)
BUT, if those value types are told to be put on the heap then they will.
i.e., If you tell the compile you want to treat it as a ref type then it
will "convert" it to a reference type and use the heap instead.
e.g.,
int x;
gives a value type x.
System.Int32 x;
will give a referenec type x;
Basically the compiler says "Oh, x is a value type so we can optimize it and
put it on the stack". If you do int x and then object y = (object)x. Then
the compiler will convert x into an object(after all, its base type is an
object since they all derive from it). This is slow cause now the compiler
has to create the object on the heap and its called boxing.
I think if you think of it as an optimization of special types then its not
a difficult concept. Basically using the special keywords you tell the
compiler they are value types... which just means that they are to be
optimized and put on the stack rather than the heap. And remember that if
you convert from optimized to non-optimzed or vice versa that there is a
penalty.
Other than that they pretty much are exactly the same. Again, int x and
Int32 x; are pretty much identical except for speed/memory issues. The heap
and stack are just memory. An object has more overhead of course and thats
why value types are faster. No reason to have overhead for something like
int x = 3;
int y = 9;
int z = x * y;
The compiler will simply do that in the most optimized way which is using
the ALU of the cpu(done in 1-2 instructions in assembly).
if you do
Int32 x = 3;
Int32 y = 9;
Int32 z = x * y;
then the compiler will treat them as full blown objects and have to find the
operator *, call the constructors, allocate memory, etc... Theres no need
for that. (although its a simple example so...)
Hope that helps,
Jon
.
- Follow-Ups:
- Re: Value Types and Reference Types
- From: Jon Skeet [C# MVP]
- Re: Value Types and Reference Types
- Prev by Date: Re: Verbatim String or Regex Pattern from Input
- Next by Date: Re: Saving image in picbox
- Previous by thread: Re: Come on guys!! Surely someone here knows something about custom serialization?
- Next by thread: Re: Value Types and Reference Types
- Index(es):
Relevant Pages
|
