none
System.ValueType and System.Object RRS feed

  • Question

  • Hi all,

     I have been programming in C# for about a year or so and is currently preparing for the MCTS Exam 70-536 hence reading the book .NET Framework  2.0 Application Development Foundation.

     Before reading the book, it seems quite reasonable and easy to think value type are int, double, float, etc and struct and reference type are all the classes. What I find hard to digest after reading the book is in Lesson 1 it says all types are derived from System.Object and in Lesson 2 it says all type inheriting from System.ValueType are not reference type and common reference type include System.Object, etc. Hm.. I started wondering doesn't that make System.ValueType a reference type since it is derived from System.Object?

     What is the magic behind System.ValueType? Is System.ValueType even a class to begin with since this article Stack & Heap in C#.NET states that anything declared with class is a reference type. Of course for the sake of the exam I can just memorize the relationship as such, but just to satisfy my curiosity. ;-) (Actually is public class XXX : System.ValueType legal code, is yes, is XXX a reference type or value type?)
    Saturday, May 3, 2008 12:18 PM

Answers

  •  

    The primary reason for having ValueType in the hierarchy is to override the implementation of Equals and GetHashCode so that they fit the value types expected behavior (comparing contents and not identity).  The primary reason for all types deriving from Object is to enable a generic view of the type system - a method that accepts an Object can then accept any argument, value type or reference type.  (This is less significant with the introduction of generics in 2.0)

     

    Finally, the fact that value types are derived from an abstract class called ValueType etc. shouldn't be confusing you.  The distinction between value types and reference types is artificial, and the inheritance constraints are also artificial.  There is no absolute definition of what it means to derive from ValueType, so this framework's decision of viewing the hierarchy is no better and no worse than other.

    Saturday, May 3, 2008 6:51 PM

All replies

  • System.ValueType is actually a reference type itself, as it's an abstract class, as is System.Enum.  These were put into the framework as a way of simplifying the hierarchical relationship between objects for developers. The runtime determines whether to store an object on a stack or on the heap based on whether the object instantiated is itself a reference or a value type.

     

    http://blogs.msdn.com/brada/archive/2003/04/17/49977.aspx

    Saturday, May 3, 2008 1:30 PM
    Moderator
  •  

    The primary reason for having ValueType in the hierarchy is to override the implementation of Equals and GetHashCode so that they fit the value types expected behavior (comparing contents and not identity).  The primary reason for all types deriving from Object is to enable a generic view of the type system - a method that accepts an Object can then accept any argument, value type or reference type.  (This is less significant with the introduction of generics in 2.0)

     

    Finally, the fact that value types are derived from an abstract class called ValueType etc. shouldn't be confusing you.  The distinction between value types and reference types is artificial, and the inheritance constraints are also artificial.  There is no absolute definition of what it means to derive from ValueType, so this framework's decision of viewing the hierarchy is no better and no worse than other.

    Saturday, May 3, 2008 6:51 PM
  • > Actually is public class XXX : System.ValueType legal code

     

    No, you would get this error:

     

    error CS0644: '_____' cannot derive from special class 'System.ValueType'

     

    This is just an aspect of the C# language, which provides a dedicated keyword "struct" for this purpose.  It is insightful to note that in the metadata for an EXE or DLL, the only thing that differentiates a "class" and a "struct" is that a class extends System.Object (or another class that is not System.ValueType) whereas a value type extends "System.ValueType".

     

    ValueType is basically a "special" behavior -- it allows instances to be allocated on the stack, but as was previously noted, they can be stored on the heap as well and in the latter case work a lot like most other objects.

    Saturday, May 3, 2008 9:34 PM
  • Hi All,

    Thanks for all of your replies, I am still have two questions on this as below:

    1. From the answers above, I got know that the value type are stored on stack, while reference type are stored on heap, but if a class have some members which is value type, then where should them be stored.

    2.For a value type, if it is assigned a object, then it will be box, like code below. My question as comments part. 

    struct TimeStruct 
    {
     private int hours, minutes, seconds;
     public TimeStruct (int hh, int min, int sec)
     {
       hours = hh;
       minutes = mm;
       seconds = sec;
     }
    }

     

    class TimeClass
    {
     private int hours, minutes, seconds;
     public TimeClass(int hh, int min, int sec)
     {
       hours = hh;
       minutes = mm;
       seconds = sec;
     }
    }
    staic void Main()
    {
     object o;
     TimeStruct nowStruct = new TimeStruct (1,2,3);
     TimeClass nowClass = new TimeClass(1,2,3);
     o = nowStruct ;
    
     //When this statement is executed, then how CLR to allocate the memory? and where is to store the data(heap or stack)? also what is the difference with initialize a class directly(TimeClass nowClass = new TimeClass();)? 
    
    }
    

     

    Thanks,

    19841020

    Sunday, August 8, 2010 4:45 AM
  • Finally, the fact that value types are derived from an abstract class called ValueType etc. shouldn't be confusing you.  

    Not a leading question, but does anyone know of some other languages that might do something like enforce no base types for structs, while providing you structs that all inherit from a reference type in the base library, and letting you use that base type except in type parameter restrictions? Does "everything inherits" come in cleaner packages, or is fuzziness the norm (to be sure it's only fuzzy to me)?

    Monday, April 30, 2012 12:17 AM