Why ValueType is class?

[Guest]

Hello,
Just curious to see why ValueType (which the base for all value types) is a
class. I thought "class" would make a type a reference type. However,
IsValueType for ValueType is returning true.
--Musthafa

 

[Jon Skeet [C# MVP]]

Just curious to see why ValueType (which the base for all value types) is a
class.

Because it doesn't make sense for it to be a value type - what would
the values be? Further, value types can't be derived from...

I thought "class" would make a type a reference type. However,
IsValueType for ValueType is returning true.

It shouldn't - ValueType is definitely a reference type. The following
code prints out "False" on my box:

using System;

class Test
{
static void Main()
{
Console.WriteLine (typeof(ValueType).IsValueType);
}
}

Could you give some code showing it returning true?

 

[Michael C]

Hello,
Just curious to see why ValueType (which the base for all value types) is
a
class. I thought "class" would make a type a reference type. However,
IsValueType for ValueType is returning true.

I believe it is a bit of trickery on the part of .net. When you declare an
int you get an int, not an object, but it needs to appear to inherit from
object so that you can assign an int to an object variable.

 

[Jon Skeet [C# MVP]]

I believe it is a bit of trickery on the part of .net. When you declare an
int you get an int, not an object, but it needs to appear to inherit from
object so that you can assign an int to an object variable.

And to make things more confusing, there are actually *two* int types
(two types for any value type, indeed) as far as the CLR is concerned -
the value type, and the boxed version of the value type. The value type
itself doesn't inherit from anything, but the boxed type inherits from
ValueType. (It's all a bit odd, frankly.)

 

[Michael C]

And to make things more confusing, there are actually *two* int types
(two types for any value type, indeed) as far as the CLR is concerned -
the value type, and the boxed version of the value type. The value type
itself doesn't inherit from anything, but the boxed type inherits from
ValueType. (It's all a bit odd, frankly.)

Actually what you just said makes it quite clear to me at least. What they
are showing in the object browser is the boxed type and the real valuetype
isn't shown at all.

Michael

 

[William Stacey [MVP]]

It is kinda mind binding, but makes some sense as you said. Allocation of
ValueType occurs on the stack and primitive types have special encoding in
metadata in the system and have explicit opcodes that can operate on them
(i.e. add, etc). ValueTypes can be moved on the gc heap via boxing by making
a copy of the instance. When on the stack, ValueTypes are not self
describing and are tracked by flow analysis. ValueTypes on the heap carry
type information (i.e. MethodTable) and are self describing.

--
William Stacey [MVP]

| | > And to make things more confusing, there are actually *two* int types
| > (two types for any value type, indeed) as far as the CLR is concerned -
| > the value type, and the boxed version of the value type. The value type
| > itself doesn't inherit from anything, but the boxed type inherits from
| > ValueType. (It's all a bit odd, frankly.)
|
| Actually what you just said makes it quite clear to me at least. What they
| are showing in the object browser is the boxed type and the real valuetype
| isn't shown at all.
|
| Michael
|
|

 

[Jon Skeet [C# MVP]]

It is kinda mind binding, but makes some sense as you said. Allocation of
ValueType occurs on the stack and primitive types have special encoding in
metadata in the system and have explicit opcodes that can operate on them
(i.e. add, etc). ValueTypes can be moved on the gc heap via boxing by making
a copy of the instance. When on the stack, ValueTypes are not self
describing and are tracked by flow analysis. ValueTypes on the heap carry
type information (i.e. MethodTable) and are self describing.

Just to clarify, that's for ValueTypes living as independent objects on
the heap.

In unboxed form, value type values can still live on the heap as part
of other objects - the type information is then part of the "owner"
object, but the value itself is not self-describing.

Just trying to avoid the "value types are allocated on the stack,
reference types are allocated on the heap" confusion which sometimes
occurs.

Jon