3

In the msdn spec, I could notice that System.Object is the ultimate base class in .Net. They say that System.ValueType is an abstract class inheriting from System.Object and overrides the methods like Equals, Compare etc... Value types like bool, int etc.. inherit from System.ValueType all the other .net objects inherits from System.Object.

I have 2 questions on this.

  1. What is the need of System.Object? Why wasn't an interface preferred over here?

Am assuming it has only 2 direct Children(ignoring that we can create more) which is System.ValueType and System.ReferenceType both having entirely different implementations.

**Edit:**There is no System.ReferenceType. There is only Sytem.Object and Sytem.ValueType (overriding the base class). Apologies here.

So System.Object may be needed to handle the basic CLR functionalities like object creation using new(), enforcing default constructor, GC etc ?

  1. When I de-compile Sytem dll, and see the implementation of bool, I just see a struct.
    For a class (say Exception) I don't see the inheritance to System.ReferenceType or System.Object. How is this inheritance handled ?
    Infact, what is Common Type System doing to MyCustomClass to make it inherit from System.Object(since the inheritance is determined at compile time am thinking CTS is doing it)

Please feel free to correct me/edit the post if my understanding is wrong.

enter image description here

Raghav
  • 2,890
  • 7
  • 36
  • 56
  • 3
    There is no `System.ReferenceType` class, so I have no idea where you got that from. – Servy Jun 02 '15 at 18:13
  • All structs implicitly inherit from `System.ValueType` that is why you don't see it in the decompiled C#. Look at the IL and it is there. – Mike Zboray Jun 02 '15 at 18:17
  • @Servy: oops.. tat was my mistake.. i edited the post – Raghav Jun 02 '15 at 18:25
  • 1
    *Why wasn't an interface preferred over here?* Because `System.Object` implements certain things. `Interfaces` *cannot actually implement anything.* You notice when you declare a class that you are **not** required to specify an implementation of `.Equals`? Because `System.Object` already provides one. If `C#` made me specify my own `.Equals` method for everything (because of the poor choice of an `interface`) I would design my own `abstract class` that everything could inherit, that would already provide such things. – Der Kommissar Jun 02 '15 at 18:29
  • 1
    Interfaces are contracts, just thin air until they are actually implemented. System.Object is structural, it plays an important role in the CLR. The object header is important, what all .NET types have in common. Also serves as a place holder for released objects on the GC heap. The struct declarations you find back for value types only match the boxed version of a value, their non-boxed representation is very different and strongly tied to the processor. – Hans Passant Jun 02 '15 at 18:33

1 Answers1

10

You have many questions in this question. In the future, consider posting one question per question.

What is the need of System.Object?

The question is vague. Let me rephrase.

Why was the C# type system designed so that all non-pointer types had a common base type?

To gain the benefits of polymorphism. In a type system that has no generics, like the C# 1.0 type system, you want to be able to make a list of arbitrary objects.

Why wasn't an interface preferred over a class type?

Interfaces specify capabilities. Base classes allow for shared implementation. The methods on Object have implementations that are shared amongst the derived types.

Am assuming it has only 2 direct Children(ignoring that we can create more) which is System.ValueType and System.ReferenceType both having entirely different implementations.

This is totally false.

So System.Object may be needed to handle the basic CLR functionalities like object creation using new()

No.

enforcing default constructor

No. Though it is true that ultimately the default constructor of object is called, that constructor doesn't do anything. So saying that the purpose of the type is to ensure that a constructor that doesn't do anything is called is a strange thing to say.

GC etc ?

No.

When I de-compile System.dll, and see the implementation of bool, I just see a struct.

Correct. You are expected to know that all non-nullable, non-enum structs inherit directly from System.ValueType.

For a class (say Exception) I don't see the inheritance to System.ReferenceType or System.Object.

Correct. You are expected to know that all class types inherit from System.Object (if no other type is specified, of course.)

How is this inheritance handled ?

The question is too vague to answer.

what is Common Type System doing to MyCustomClass to make it inherit from System.Object(since the inheritance is determined at compile time am thinking CTS is doing it)

I have absolutely no idea what you're trying to ask here. Try making the question more precise.

A question you did not ask but probably should have asked is:

What does it mean when I say that type A inherits from type B?

It means that all members of type B are also members of type A.

All members? Even private members?

Yes. Inheritance is the property that the members of one type are also members of another.

Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
  • 2
    If I may guess at the purpose of last _actual_ question, I would think the OP means "How/When/Where does the Compiler/JIT/CTS/CLR define my class as inheriting from `object` if I do not specify a different base class"? – D Stanley Jun 17 '15 at 20:05