Is Class Synonymous with Type?

[garyusenet]

I'm using an example piece of code: -
namespace Wintellect.Interop.Sound{
using System;
using System.Runtime.InteropServices;
using System.ComponentModel;

sealed class Sound{
public static void MessageBeep(BeepTypes type){
if(!MessageBeep((UInt32) type)){
Int32 err = Marshal.GetLastWin32Error();
throw new Win32Exception(err);
}
}

[DllImport("User32.dll", SetLastError=true)]
static extern Boolean MessageBeep(UInt32 beepType);

private Sound(){}
}

enum BeepTypes{
Simple = -1,
Ok = 0x00000000,
IconHand = 0x00000010,
IconQuestion = 0x00000020,
IconExclamation = 0x00000030,
IconAsterisk = 0x00000040
}
}


In the right up one part of explanation states. "Starting from the top,
you will notice that an entire type named Sound is devoted to
MessageBeep. If I need to add support for playing waves using the
Windows API function PlaySound, I could reuse the Sound type. However,
I am not offended by a type that exposes a single public static method.
"

Now i thought a type was a classifcation of variable, and a Class was a
blueprint for a real world thing. Can you tell me am i confusing two
meanings of type here?

or does type simply mean the same thing as class?

Thanks,

Gary-

 

[Brian Gideon]

I'm using an example piece of code: -
namespace Wintellect.Interop.Sound{
using System;
using System.Runtime.InteropServices;
using System.ComponentModel;

sealed class Sound{
public static void MessageBeep(BeepTypes type){
if(!MessageBeep((UInt32) type)){
Int32 err = Marshal.GetLastWin32Error();
throw new Win32Exception(err);
}
}

[DllImport("User32.dll", SetLastError=true)]
static extern Boolean MessageBeep(UInt32 beepType);

private Sound(){}
}

enum BeepTypes{
Simple = -1,
Ok = 0x00000000,
IconHand = 0x00000010,
IconQuestion = 0x00000020,
IconExclamation = 0x00000030,
IconAsterisk = 0x00000040
}
}


In the right up one part of explanation states. "Starting from the top,
you will notice that an entire type named Sound is devoted to
MessageBeep. If I need to add support for playing waves using the
Windows API function PlaySound, I could reuse the Sound type. However,
I am not offended by a type that exposes a single public static method.
"

Now i thought a type was a classifcation of variable, and a Class was a
blueprint for a real world thing. Can you tell me am i confusing two
meanings of type here?

or does type simply mean the same thing as class?

Thanks,

Gary-

Gary

Yes, a class and a type are similar concepts. A class is the mechanism
you use in C# to create a new type.

Brian

 

[Peter Bradley]

A class defines a type. So it's a type of type. An int is another type of
type. Structs and Enums are other types of types. Structs, Enums and
classes are examples of user-defined types. Ints, floats, longs etc are
examples of native types.

Less facetiously, a type is (simplistically) an area of memory that the
runtime treats as a single thing. Objects are instances of reference types
(you only ever get a pointer to them). Structs and native types like ints
are value types (variables of these types are labels for the first address
location associated with the value).

If all I've done is confuse you still further, please let me know and I'll
try again at more length.


Peter

 

[Dustin Campbell]

Now i thought a type was a classifcation of variable, and a Class was

a blueprint for a real world thing. Can you tell me am i confusing two
meanings of type here?

All classes are types but not all types are classes. In C#, a type could be:

1. Class
2. Interface
3. Struct
4. Enum
5. Delegate

Any of these can be used to classify a variable. For example:

class Employee { }

private void TestEmployee()
{
// Here is a variable whose type is a class.
Employee emp = new Employee();
}

Best Regards,
Dustin Campbell
Developer Express Inc

 

[Brian Gideon]

Yes, a class and a type are similar concepts. A class is the mechanism
you use in C# to create a new type.

Err...a class is *a* mechanism for creating a new type. It's not *the*
mechanism.

 

[Oliver Sturm]

Hello,

In addition to what others have already mentioned, you should also be
aware that in .NET there's actually a class called Type, which is (not
surprisingly) used to hold information about a type. Basically .NET lets
you analyze types and other language elements at runtime using a process
known as Reflection, and the information resulting from this analysis is
sometimes stored in classes of type Type. I'll stop now before I sound
like a Monty Python parody


Oliver Sturm

 

[garyusenet]

Thankyou all very much. It is quite a lot clearer now thankyou.

One question though. At the moment (i hope i haven't misunderstood) My
understanding is that all types are ultimately defined in a class.
'native types' already have their classes defined, and user types are
defined by individual users in new classes.

But it was said in this thread that a class, is a type of type.

So i guess my understanding must still be a bit flawed, for if a type
is defined by a class, and a class is a type of type, the class type
would have to be defined in a class and we would have an infinite
amount of classes each defining each other.

Can someone clarify this for me please?

Thankyou

 

[Peter Bradley]

Remember not all types are classes. Native types are just that. Native
types. They are not classes (unless they've been converted into special
classes, by boxing for example). They are ints, floats, doubles, bytes etc
etc. - and nothing else.

Similarly Structs are not classes. They are structs. Structs are another
type of type: user defined value types, as it happens. As someone else has
pointed out, there are also enumeration types, delegate types, interface
types, even Type types.

In this respect, C# is not completely OO. For that you have to look at
something like Smalltalk, where everything is a class (or a meta class) - or
an object, of course. Java sort of goes part way by defining classes that
encapsulate the native types. C# does something similar with boxing.

Remember, a type, when instantiated, is just a bit of memory defined either
by a reference (pointer) for reference types, or a label for value types.

Languages do not have to be OO to have types. C is not OO and has types.
The type is what you put before a variable when you declare it:

int i;
float f;
char* s;

The above declare three variables in C of type int, float and pointer to
char respectively.

You do pretty much the same sort of thing in C#:

int i;
float f;
string s;

Post again if you're still confused.


HTH


Peter


The same goes for Enums, Delegates and all the other things that have been
mentioned.

 

[Oliver Sturm]

I think the statement "a class is just one particular type of type" refers
to the fact that there are other "things" that can also referred to as
types. Like structs, for example, which are so-called "value types" in
..NET, and are not classes.

To be honest, I do think that the assessment "a class is very similar to a
type" is correct for many intents and purposes. It's not technically
perfect, but it brings the point across pretty well

As an example, when you read literature about object oriented programming,
you may sometimes find people refer to classes and objects, with the
important difference being that objects are instances of classes. So the
class is basically the declaration of something, while the object is the
actual incarnation of it. And in this sense, a type is really very similar
to a class - it describes something in detail, something that doesn't
actually have to exist at that point. Technically speaking, that thing
that is being described might not be a class after all, that's where the
disagreement comes in.


Oliver Sturm

 

[garyusenet]

Thanks again I've got an enormous amount out of your kind explanations.


One last question on the subject from me!

If native types aren't defined in classes where are they defined? For
instance when I try to assign a value greater than
18,446,744,073,709,551,615 to a long condition variable as part of a
for loop. It is underlined in red and if I hover over it i'm told that
my Intergral constant is too large.

e.g.
for (i = 0; i < 99999999999999999999; i++)

Where is it actually written that I cant assign a value this large to a
long?

The reason i thought every type would be defined in a class is i
thought then the constructor could have some code to check the size of
the value being assigned. But if this isn't the case, where does this
logic take place?

Thanks again!

Gary-

 

[Kevin Spencer]

Actually, all managed types ARE classes.

Interface, struct, enum all inherit the System.ValueType class, which
inherits System.Object. The following is a list of all types that inherit
System.ValueType:

http://msdn2.microsoft.com/en-gb/library/aa904377(VS.71).aspx

System.Delegate is simply a class which inherits System.Object.

Therefore, a type and a class are synonymous in the .Net Framework.

--
HTH,

Kevin Spencer
Microsoft MVP
Logostician
http://unclechutney.blogspot.com

There is a madness to my method.

 

[Kevin Spencer]

So-called "Native Types" (int, double, struct, enum, etc) ARE classes, which
inherit System.ValueType, which inherits System.Object. See:

http://msdn2.microsoft.com/en-gb/library/aa904377(VS.71).aspx
http://msdn2.microsoft.com/en-gb/library/system.valuetype(VS.71).aspx

ALL types are classes. And all classes are types.

And in this respect, C# (and more importantly, the CLI) is COMPLETELY OO.

--
HTH,

Kevin Spencer
Microsoft MVP
Logostician
http://unclechutney.blogspot.com

There is a madness to my method.

 

[Dustin Campbell]

Actually, all managed types ARE classes.

Yes, I'm aware of that. However, I was listing the various kinds of types
that can be defined in C#.

Interface, struct, enum all inherit the System.ValueType class, which
inherits System.Object. The following is a list of all types that
inherit System.ValueType:

Interface does not inherit from System.ValueType.
Structs do inherit from System.ValueType.
Enums inherit from System.Enum -- which inherits from System.ValueType.

System.Delegate is simply a class which inherits System.Object.

Delegates actually decend from System.MulticastDelegate -- which descends
from System.Delegate.

Therefore, a type and a class are synonymous in the .Net Framework.

I was attempting to demonstrate the difference in C# -- not the .NET framework.
It is true that everything eventually descends from System.Object and, in
metadata is a class. However, I'm not sure that's relevant here since the
discussion is about C#. So, re-worded for clarity:

All C# classes are .NET types but not all .NET types are C# classes.

Best Regards,
Dustin Campbell
Developer Express Inc.

 

[Peter Bradley]

In the standard.

The language infrastructure takes care of it all for you for native types.
For example it knows that a signed int32 is 32 bits, each representing a
power of 2, with the leftmost bit representing the sign (IIRC). For floats
and doubles it knows all about mantissas and exponents.

For non-class-based user defined types, like structs, you do at least a part
of it when you define the struct (or whatever). What you are doing is
telling the language infrastructure how much memory it needs to allocate for
this particular type of datastructure, whether it needs to allocate it on
the stack (value types) or the heap (reference types), and how that block of
memory is logically divided. The infrastructure knows how to reference the
various parts of instances of the data type you've defined. Once again,
it's in the standard and relies on you following the syntax of the language
for it to work (e.g. using dot notation for structs).

HTH (and keep asking questions if you're interested)


Peter

 

[Peter Bradley]

Nice one. Thanks


Peter

So-called "Native Types" (int, double, struct, enum, etc) ARE classes,
which inherit System.ValueType, which inherits System.Object. See:

http://msdn2.microsoft.com/en-gb/library/aa904377(VS.71).aspx
http://msdn2.microsoft.com/en-gb/library/system.valuetype(VS.71).aspx

ALL types are classes. And all classes are types.

And in this respect, C# (and more importantly, the CLI) is COMPLETELY OO.

--
HTH,

Kevin Spencer
Microsoft MVP
Logostician
http://unclechutney.blogspot.com

There is a madness to my method.

 

[Marc Gravell]

Well, I think that depends on your definition of class; the runtime, for
instance, doesn't agree:

struct MyStruct { }
static void Main()
{
Console.WriteLine(typeof(MyStruct).IsClass);
}

(note: using a custom struct just for illustration; also applies to Int32
etc)

Marc

 

[Marc Gravell]

(ignore my last post; re-reading your post, it might just be wording that we
are tripping over here...)

Marc

 

[Dustin Campbell]

ALL types are classes. And all classes are types.

However, that statement simply confuses C# developers because the next questions
are often: "so what's a struct? Is that a class too? Then, why don't I declare
it with the 'class' keyword?"

While all types are .NET classes that descend from System.Object (excepting
System.Object itself) is completely true on the metadata-level, the CLR does
not treat all types the same and it is important to make distinctions between
value types and reference types. Because if you don't, the simply confuse
the novice C# developer later.

Best Regards,
Dustin Campbell
Developer Express Inc.

 

[Dave Sexton]

Hi Dustin,

However, that statement simply confuses C# developers because the next
questions are often: "so what's a struct? Is that a class too? Then, why
don't I declare it with the 'class' keyword?"

ValueType adds additional semantics to classes. Using "struct" instead of
"class" tells the C# compiler that you would like to use those additional
semantics (and behavior) in your class, type, object - whatever. "enum"
does something similar, but to structures (value-types, which are also
classes, types and objects - whatever , etc.

While all types are .NET classes that descend from System.Object
(excepting System.Object itself) is completely true on the metadata-level,
the CLR does not treat all types the same and it is important to make
distinctions between value types and reference types. Because if you
don't, the simply confuse the novice C# developer later.

I agree that the distinction is important, but I think it's the distinction
itself that commonly confuses novice developers regardless of whether it
becomes apparent sooner or later in their exploration of C#. Though, I
think that making these distinctions later allows novices to focus on syntax
and grammar, which should definitely come first, IMO. As soon as they ask,
"What's a struct?", as you put it, or, "Where did the value of this variable
go?", that's when a conversation such as this should take place

 

[Dustin Campbell]

ALL types are classes. And all classes are types.

ValueType adds additional semantics to classes. Using "struct"
instead of "class" tells the C# compiler that you would like to use
those additional semantics (and behavior) in your class, type, object
- whatever. "enum" does something similar, but to structures
(value-types, which are also classes, types and objects - whatever ,
etc.

'Twas merely a rhetorical question Dave. I know that you know that I'm comfortable
with value types (and vice versa). :-D

I agree that the distinction is important, but I think it's the
distinction itself that commonly confuses novice developers regardless
of whether it becomes apparent sooner or later in their exploration of
C#. Though, I think that making these distinctions later allows
novices to focus on syntax and grammar, which should definitely come
first, IMO. As soon as they ask, "What's a struct?", as you put it,
or, "Where did the value of this variable go?", that's when a
conversation such as this should take place

Truely stated. I guess that the point that I want to make is that, the blanket
statement that "all types are classes and all classes are types" is going
to be more confusing than helpful to a novice C# developer because it mixes
metaphors a bit between the framework and the language. A better approach
might be to simply say (as Jeffrey Richter does), "all types are derived
from System.Object". That is a clear statement about a truth in the .NET
framework and won't be confused with the semantics of the C# language. In
fact, understanding that truth is necessary before any of the other details
about types (e.g. boxing, reference vs. value types, object equality and
identity, etc.).

Best Regards,
Dustin Campbell
Developer Express Inc.