Re: Value Types and Reference Types

Jon Slaughter <Jon_Slaughter@xxxxxxxxxxx> wrote:
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

No, the compiler doesn't have a list of them. The type metadata
determines whether or not it's a value type.

and will stick them on the stack instead of the heap when used.

Well, that depends:
http://pobox.com/~skeet/csharp/memory.html

(struct is a general type that gets this priviledge but is made up of the
more simple types)

Struct isn't a type in itself, it's just the way you declare a value
type in C#.

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;

No it won't. int is just an alias for System.Int32. The two lines of
code above are exactly equivalent.

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.

Well, I wouldn't say it's actually slow. It will cause a performance
hit if you do it millions and millions of times, but it's no slower
than creating other objects.

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

There's more to it than that. See
http://pobox.com/~skeet/csharp/references.html

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...)

It's also an incorrect example, for the reason given earlier.

--
Jon Skeet - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk
.

Relevant Pages

  • Re: Value Types and Reference Types
    ... So your saying that an int is not special? ... What I mean is that the compiler ... Boxing definitely creates an object on the heap. ... Int32 x; are pretty much identical except for speed/memory issues. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Direction in which the process stack grows
    ... >> int main ... > would force the compiler to create local variables in the same ... > sequence on the stack as you define them in the source code. ... > with gcc and either without optimization or inlining explicitely ...
    (comp.unix.programmer)
  • Re: calling convention stdcalll and cdecl call
    ... the compiler can somehow figure out how the function accesses its parameters, it can figure out how many there are, and pop the stack correctly without any additional information from the caller. ... int find{ ... This is similar to how it must take some action for a __stdcall member function, ...
    (microsoft.public.vc.language)
  • Re: where do the automatic variables go ?
    ... and bss segments etc...but there is notthing like stack and heap ... Stack variables are implied by the compiler (the compiler generates code ... int foo ...
    (comp.os.linux.misc)
  • Re: Do buffers always start with the lowest memory address being the first element?
    ... > The C standard does not assume a downward-growing stack, ... > an upward-growing stack. ... C allows but does not require that the array produced ... > machine depends on both the C compiler and the machine. ...
    (comp.lang.c)
Loading