whay all types in .net are inherited from System.Object ?

All types are not. All classes are. That is because all classes have the
same underlying properties at their core. It is a principle of OOP
(inheritance).

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Show me your certification without works,
and I'll show my certification
*by* my works.

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> whay all types in .net are inherited from System.Object ?
>

speaking in terms .net, how would you differentiate between a type and a
class ?

"Kevin Spencer" wrote:

> All types are not. All classes are. That is because all classes have the
> same underlying properties at their core. It is a principle of OOP
> (inheritance).
>
> --
> HTH,
>
> Kevin Spencer
> Microsoft MVP
> Professional Numbskull
>
> Show me your certification without works,
> and I'll show my certification
> *by* my works.
>
> <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > whay all types in .net are inherited from System.Object ?
> >
>
>
>

Let me put it first in terms NOT .Net: A square is a rectangle, but a
rectangle is not necessarily a square. A rectangle is only a square if all
of its sides are of the same length. Similarly, a class is a type, but a
type is not necessarily a class. Value types, such as integers,
enumerations, and structs, are not classes.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Show me your certification without works,
and I'll show my certification
*by* my works.

"Arif Khan" <(E-Mail Removed)> wrote in message
news:2A173321-F0EC-475B-ABCE-(E-Mail Removed)...
> speaking in terms .net, how would you differentiate between a type and a
> class ?
>
> "Kevin Spencer" wrote:
>
>> All types are not. All classes are. That is because all classes have the
>> same underlying properties at their core. It is a principle of OOP
>> (inheritance).
>>
>> --
>> HTH,
>>
>> Kevin Spencer
>> Microsoft MVP
>> Professional Numbskull
>>
>> Show me your certification without works,
>> and I'll show my certification
>> *by* my works.
>>
>> <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>> > whay all types in .net are inherited from System.Object ?
>> >
>>
>>
>>

well let me make sure I clearly understand your point:

I am quoting following lines from .net Components Book from Juval Lowy Page:
544

"The abstract class Type, defined in the System namespace, is an abstraction
of a .NET CLR type. Every .NET type, be it a .NET-provided type(from value
types such as integers and enums to classes and interfaces) or a
developer-defined type, has a corresponding unique Type value.

The canonical base class of any .NET type is System.Object. ..."

If I am understanding it right, you mentioned in your second posting, "All
types are not. All classes are." to the original question "whay all types in
..net are inherited from System.Object ?"

If we look at MSDN it shows
(http://msdn.microsoft.com/library/de...classtopic.asp) it shows:
System.Object
System.ValueType
System.Int32

By looking at the above text, how would you define the relationship between
System.Object->System.ValueType->System.Int32 ?



"Kevin Spencer" wrote:

> Let me put it first in terms NOT .Net: A square is a rectangle, but a
> rectangle is not necessarily a square. A rectangle is only a square if all
> of its sides are of the same length. Similarly, a class is a type, but a
> type is not necessarily a class. Value types, such as integers,
> enumerations, and structs, are not classes.
>
> --
> HTH,
>
> Kevin Spencer
> Microsoft MVP
> Professional Numbskull
>
> Show me your certification without works,
> and I'll show my certification
> *by* my works.
>
> "Arif Khan" <(E-Mail Removed)> wrote in message
> news:2A173321-F0EC-475B-ABCE-(E-Mail Removed)...
> > speaking in terms .net, how would you differentiate between a type and a
> > class ?
> >
> > "Kevin Spencer" wrote:
> >
> >> All types are not. All classes are. That is because all classes have the
> >> same underlying properties at their core. It is a principle of OOP
> >> (inheritance).
> >>
> >> --
> >> HTH,
> >>
> >> Kevin Spencer
> >> Microsoft MVP
> >> Professional Numbskull
> >>
> >> Show me your certification without works,
> >> and I'll show my certification
> >> *by* my works.
> >>
> >> <(E-Mail Removed)> wrote in message
> >> news:(E-Mail Removed)...
> >> > whay all types in .net are inherited from System.Object ?
> >> >
> >>
> >>
> >>
>
>
>

The word "type" is a general term which indicates a definition of the most
basic characteristics of binary data. All data and code in a computer is
binary, meaning that it is 1 or more 1's and 0's. In order for the computer
to work with data, it needs to know something about the basic definition of
the data. What is the difference between 10001011 and 10001011? Well, both
are 8-bits in size, and both have 1's and 0's in the same order and
position. However, depending upon the data type they represent, they can
represent any of several different "types" of data. For example, one might
represent an unsigned byte, and one might represent a signed byte (a byte is
8 bits of data). A signed byte uses the 8th bit to represent the sign
(positive or negative), and can therefore store only half the value of an
unsigned bit, bit either positive or negative, while an unsigned byte can
not represent a negative number. One might represent a number, while the
other represents a character.

The type of the data tells the computer how to work with it, what size it is
(all data in a computer is consecutive), and the like.

Of course, as time has gone by, the word "type" has grown in scope, but
remains the same basic principle.

> I am quoting following lines from .net Components Book from Juval Lowy
> Page:
> 544
>
> "The abstract class Type, defined in the System namespace, is an
> abstraction
> of a .NET CLR type. Every .NET type, be it a .NET-provided type(from value
> types such as integers and enums to classes and interfaces) or a
> developer-defined type, has a corresponding unique Type value.
>
> The canonical base class of any .NET type is System.Object. ..."

> If I am understanding it right, you mentioned in your second posting, "All
> types are not. All classes are." to the original question "whay all types
> in
> .net are inherited from System.Object ?"

I can understand your confusion. In one way, value types are indeed
inherited from System.Object, in that in the CLR, all value types are
classes derived from System.ValueType. However, in another sense, they are
not objects in that the underlying object is not used unless it is needed,
and then is converted to an object type by virtue of Boxing and Unboxing.

In other words, when you create an integer, like so:

int i = 10;

The actual space allocated on the stack for "i" is 32 bits, the space needed
to store the "naked" integer. At this point, the data itself is not a class;
it is a literal integer. However, when you treat it like System.Int32, by
using any of the class properties, it is "boxed" into an instance of the
System.Int32 class.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Show me your certification without works,
and I'll show my certification
*by* my works.

Kevin, thanks for your detailed response, regarding boxing of "naked"
integer, can you please clarify in the following code when exactly a
literal integer will be boxed into an instance? Exactly speaking do you
think calling GetHashCode or ToString on a declared "naked" integer
will cause it to box? or only by specifically casting it to an object
will box it ?

class abc
{

function void TestInteger()
{
int a;
a = 10; //literal or naked integer

int b = a.GetHashCode(); // Will 'a' be Boxed or remain naked integer ?
string c = a.ToString(); // Will 'a' be Boxed or remain naked integer ?

object o = (object) i; //Will be boxed.
}
}

You're quite welcome. This stuff can be confusing.

> int a;
> a = 10; //literal or naked integer

As long as you treat the variable "a" as if it were an integer, it will
remain unboxed, as in these 2 cases.

> int b = a.GetHashCode(); // Will 'a' be Boxed or remain naked integer ?
> string c = a.ToString(); // Will 'a' be Boxed or remain naked integer ?
>
> object o = (object) i; //Will be boxed.

In these cases, you are calling a method of the System.Int32 class, in which
case the variable is boxed as an instance of the System.Int32 class.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Show me your certification without works,
and I'll show my certification
*by* my works.

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Kevin, thanks for your detailed response, regarding boxing of "naked"
> integer, can you please clarify in the following code when exactly a
> literal integer will be boxed into an instance? Exactly speaking do you
> think calling GetHashCode or ToString on a declared "naked" integer
> will cause it to box? or only by specifically casting it to an object
> will box it ?
>
> class abc
> {
>
> function void TestInteger()
> {
> int a;
> a = 10; //literal or naked integer
>
> int b = a.GetHashCode(); // Will 'a' be Boxed or remain naked integer ?
> string c = a.ToString(); // Will 'a' be Boxed or remain naked integer ?
>
> object o = (object) i; //Will be boxed.
> }
> }
>

Kevin Spencer <(E-Mail Removed)> wrote:
> You're quite welcome. This stuff can be confusing.

Apparently so

> > int a;
> > a = 10; //literal or naked integer
>
> As long as you treat the variable "a" as if it were an integer, it will
> remain unboxed, as in these 2 cases.
>
> > int b = a.GetHashCode(); // Will 'a' be Boxed or remain naked integer ?
> > string c = a.ToString(); // Will 'a' be Boxed or remain naked integer ?
> >
> > object o = (object) i; //Will be boxed.
>
> In these cases, you are calling a method of the System.Int32 class, in which
> case the variable is boxed as an instance of the System.Int32 class.

System.Int32 isn't a class, it's a struct.

Neither the call to GetHashCode nor the call to ToString results in a
box operation, as can be easily verified with ildasm.

The cast to object, however, *does* involve a box.


It gets more confusing though when talking about other value types
which *don't* override GetHashCode and ToString themselves. Consider
the following code:

using System;

struct Foo
{
}

class Test
{
static void Main()
{
Foo a = new Foo();

int b = a.GetHashCode();
string c = a.ToString();

object o = (object) a;
}
}

In C# 1.1, the calls to GetHashCode and ToString both involve a boxing
operation. In C# 2.0, however, the "constrained." IL prefix is used,
which avoids a box.

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Hi Jon,

I certainly did step on the class/struct thing. In too much of a hurry, I'm
afraid. I did know that Int32 is a struct, but got sloppy. Been putting in
too many hours lately.

As for the boxing explanation, I did not realize that. I was certain that
GetHashCode or ToString would result in a boxing operation, because they are
both methods of System.Object, and they are listed in the SDK as being
overridden. The assumption I made was that they override the System.Object
methods, rather than the System.ValueType methods.

Thanks for the ...clarification?

--
;-),

Kevin Spencer
Microsoft MVP
Professional Numbskull

Show me your certification without works,
and I'll show my certification
*by* my works.

"Jon Skeet [C# MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Kevin Spencer <(E-Mail Removed)> wrote:
>> You're quite welcome. This stuff can be confusing.
>
> Apparently so
>
>> > int a;
>> > a = 10; //literal or naked integer
>>
>> As long as you treat the variable "a" as if it were an integer, it will
>> remain unboxed, as in these 2 cases.
>>
>> > int b = a.GetHashCode(); // Will 'a' be Boxed or remain naked integer ?
>> > string c = a.ToString(); // Will 'a' be Boxed or remain naked integer ?
>> >
>> > object o = (object) i; //Will be boxed.
>>
>> In these cases, you are calling a method of the System.Int32 class, in
>> which
>> case the variable is boxed as an instance of the System.Int32 class.
>
> System.Int32 isn't a class, it's a struct.
>
> Neither the call to GetHashCode nor the call to ToString results in a
> box operation, as can be easily verified with ildasm.
>
> The cast to object, however, *does* involve a box.
>
>
> It gets more confusing though when talking about other value types
> which *don't* override GetHashCode and ToString themselves. Consider
> the following code:
>
> using System;
>
> struct Foo
> {
> }
>
> class Test
> {
> static void Main()
> {
> Foo a = new Foo();
>
> int b = a.GetHashCode();
> string c = a.ToString();
>
> object o = (object) a;
> }
> }
>
> In C# 1.1, the calls to GetHashCode and ToString both involve a boxing
> operation. In C# 2.0, however, the "constrained." IL prefix is used,
> which avoids a box.
>
> --
> Jon Skeet - <(E-Mail Removed)>
> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
> If replying to the group, please do not mail me too