Two questions about C# datatypes

[Piotrekk]

Hi

1. int is value type so it is stored on stack. class is reference type
and it is stored on heap.
What is where when we declare class which contains sturct which
contains int. I suppose that even in this example ALL value types are
on stack. Otherwise I wouldn't understand it at all since visual
studio C# project puts evertyhing into a class. Since classes are ref
types I assume that everything that is in the class and derives from
object goes to heap. Is that true?

2. How exactly compiler detects type if an object such that it can
detect wrong casts? I would appreciate also any links.

Kind regards
Piotr Kolodziej

 

[Jon Skeet [C# MVP]]

1. int is value type so it is stored on stack. class is reference type
and it is stored on heap.

No, it's not that simple. It's unfortunate that some people perpetuate
this myth.

What is where when we declare class which contains sturct which
contains int. I suppose that even in this example ALL value types are
on stack.

No.

See http://pobox.com/~skeet/csharp/memory.html

Otherwise I wouldn't understand it at all since visual
studio C# project puts evertyhing into a class. Since classes are ref
types I assume that everything that is in the class and derives from
object goes to heap. Is that true?

Hopefully the above link will clarify things for you.

2. How exactly compiler detects type if an object such that it can
detect wrong casts? I would appreciate also any links.

Not sure exactly what you mean here.

 

[Marc Gravell]

so it is stored on stack
As a *method variable* it is stored on the stack; as a field (i.e.
instance variable) it is stored with the instance, which could be on
either the heap or the stack.

Marc

 

[Piotrekk]

This link is that what was missing in my brain ;-)
Thanks

 

[Lasse Vågsæther Karlsen]

Hi

1. int is value type so it is stored on stack. class is reference type
and it is stored on heap.
What is where when we declare class which contains sturct which
contains int. I suppose that even in this example ALL value types are
on stack. Otherwise I wouldn't understand it at all since visual
studio C# project puts evertyhing into a class. Since classes are ref
types I assume that everything that is in the class and derives from
object goes to heap. Is that true?

2. How exactly compiler detects type if an object such that it can
detect wrong casts? I would appreciate also any links.

Kind regards
Piotr Kolodziej

Value types in classes is stored inside the class. Reference types in
classes stores a reference in the class to the object on the heap.

For your example, a class containing a struct will create an object
where the struct is part of the memory allocated to the object. The int
inside the struct is thus inside the struct.

In other words, like this:

reference -> [ Object ---- [ Struct --- [ Int32 ] --- ] ---- ]

An object has a hidden pointer to a structure containing information
about the class it has been created from. That's how GetType() can get
the right Type object, how "is" and "as" works, etc.

 

[Scott Roberts]

See http://pobox.com/~skeet/csharp/memory.html

Your article states:

"Note that a value type variable can never have a value of null - it
wouldn't make any sense, as null is a reference type concept, meaning "the
value of this reference type variable isn't a reference to any object at
all". "

How does this statement line up with nullable types? Are nullable types
reference variables?

 

[Marc Gravell]

They are structs, so aren't "nullable" in the regualar sense of having
a true null reference; however, both the compiler and runtime have
special support for Nullable<T> that makes it look like such:

When it spots Nullable<T>, the compiler adds the necessary calls to
..HasValue and .Value* to do the correct thing - i.e. "if(x!=null)"
becomes "if(x.HasValue)" - and similar for operators (so-called
"lifted" operators).

Likewise, the runtime has different boxing rules; a Nullable<T>
without a value (when cast as "object") becomes null (instead of a
reference to a box containing the Nullable<T>) - and the same in the
reverse (null becomes a Nullable<T> without a value).

*=actually IIRC it uses GetValueOrDefault(), but don't worry about
that ;-p

Marc

 

[Scott Roberts]

They are structs, so aren't "nullable" in the regualar sense of having a
true null reference; however, both the compiler and runtime have special
support for Nullable<T>

Makes sense. Thanks.

 

[Jon Skeet [C# MVP]]

Your article states:

"Note that a value type variable can never have a value of null - it
wouldn't make any sense, as null is a reference type concept, meaning "the
value of this reference type variable isn't a reference to any object at
all". "

How does this statement line up with nullable types? Are nullable types
reference variables?

See Marc's response for an accurate answer - the article was written
before C# 2 came along, and I need to update it further...