ansaurus

Question

How .NET differentiates reference vs primitive and value types

Answer 1

+2 A:

Value types are actually derived from System.ValueType which itself is derived from System.Object.

Matthew Vines 2009-08-31 18:14:23

Answer 2

+11 A:

All value types, including built-in Common Type System (CTS) primitives, derive DIRECTLY from the CTS type "System.ValueType", (except enums).

So the compiler can tell by examining any types' base type. If it is "System.ValueType", then it's a value type, otherwise, it's a reference type.

Edit: Enums, as in

public Enum Shipper {FedEx, Aerborne, USPS, Stork}

... do not derive Directly from System.ValueType, they derive from System.Enum, which derives from System.ValueType...

Charles Bretana 2009-08-31 18:14:41

Except for `System.Enum`, which derives from `System.ValueType` but is not a value type itself. But all `enum` types *are* value types which derive from `System.Enum` making their base type not `System.ValueType`. So value types are types derived from `System.ValueType` except for `System.Enum`, although the internal implementation of this test can be performed more efficiently than this.

280Z28 2009-08-31 18:20:41

Thanks Charles. Does java works in similar way?

Gopalakrishnan Subramani 2009-08-31 18:28:31

@280Z28: I'm not sure what that means, as System.Enum is not a type you can directly use. In fact, it's not even real enough to use as a constraint on a generic type (see bottom of http://msdn.microsoft.com/en-us/library/d5x73970.aspx).

Steven Sudit 2009-08-31 18:59:46

@280Z28 Please calrify 'Except for System.Enum, which derives from System.ValueType but is not a value type itself.'

P.K 2009-08-31 19:04:06

@280Z28. Enums are an exception, in that they must derive from System.Enum, which is just a specialization of an integral type (short, int, long, etc.) that does not add any new fields to the integral type but simply restricts the value space which is allowed. Any enumeration type must specify a second type which will be used as the core integral type, to hold the data representation. This second core integral type, of course, derives from System.ValueType. And YES, enums ARE value types.

Charles Bretana 2009-08-31 19:15:06

Enums are not an exception as System.Enum derives from System.ValueType so the same type checking applies event to them.

Matthew Vines 2009-08-31 19:29:23

@Matthew, Perhaps we are hitting the level of irelevance of detail here, but although they do indirectly derive from System.ValueType, because (and frankly I am not sure of the distinction here...) either System.Enum derives from System.ValueType, or the CTS Integral type that they extend (int, short etc.) derives from System.ValueType. But the enum itself does not derive directly from System.ValueType, it derives from System.Enum...

Charles Bretana 2009-08-31 19:42:44

@Steven, the limitation on using `System.Enum` is an artificial C# limitation. You can happily define such a constraint in C++/CLI, for example, or in MSIL directly.

Pavel Minaev 2009-08-31 21:34:05

@PK: `System.Enum` is not a value type in a sense that you can write `System.Enum x = null`.

Pavel Minaev 2009-08-31 21:35:06

From CLR perspective, enums do not derive from their underlying integral value types. If you look at a disassembly of an enum, you'll see that it rather wraps a field of that integral type. Where enums are special is that CLR guarantees that they are "assignment compatible" (i.e. bitwise representation is exactly the same) as their underlying integral type. However, enum is a value type strictly because it derives (indirectly) from `System.ValueType` - its underlying type has nothing to do with this.

Pavel Minaev 2009-08-31 21:37:36

Answer 3

+2 A:

Value types are derived from System.ValueType, which, among other things, gives a default (but slow) implementation of GetHashCode and Equals. (They're slow because they use reflection).

Primitive types like int can be boxed into value types in IL using the box instruction. They have special IL instructions to work with them.

Reference types are all other classes.

There are also pointers, which can be used in unsafe code and do not derive from object at all. EDIT - proof.

SLaks 2009-08-31 18:16:32

Are you sure pointer types don't derived from IntPtr?

Steven Sudit 2009-08-31 19:03:41

Yes, they're completely unrelated. For one thing, `IntPtr` is a struct, and you can't derive from a struct.

SLaks 2009-08-31 21:12:29

ansaurus

tags:

views:

answers:

How .NET differentiates reference vs primitive and value types

related questions