structs vs. classes???

[max caber]

I am having a hard time understanding the difference between a "struct" and
a "class". Please explain why and where you would use a "struct" instead
of a "class". The following code demonstrates that structs can have constructors,
methods and propterties. Are they that different from classes that they
are needed?

public struct StructOne
{
public int a;
string s;

public StructOne(int a,string s)
{
this.a=a;
this.s=s;
}
public void display()
{
Console.WriteLine(this.ToString());
}
public override String ToString()
{
return this.a + " : " + this.s;
}
public string S
{
set{s=value;}
get{return this.s;}
}
}

class ClientMain
{
static void Main(string[] args)
{
StructOne s1 = new StructOne(1,"hello");
s1.a = 2;
s1.S = "world";
s1.display();
Console.WriteLine(s1.ToString());
}
}

[Rob Teixeira]

Yes, they are different. Structures are Value types and not Reference types.

-Rob

"max caber" <maxcaber@yahoo.com> wrote:
>
>I am having a hard time understanding the difference between a "struct"
and
>a "class". Please explain why and where you would use a "struct" instead
>of a "class". The following code demonstrates that structs can have constructors,
>methods and propterties. Are they that different from classes that they
>are needed?
>
>public struct StructOne
> {
> public int a;
> string s;
>
> public StructOne(int a,string s)
> {
> this.a=a;
> this.s=s;
> }
> public void display()
> {
> Console.WriteLine(this.ToString());
> }
> public override String ToString()
> {
> return this.a + " : " + this.s;
> }
> public string S
> {
> set{s=value;}
> get{return this.s;}
> }
> }
>
>class ClientMain
> {
> static void Main(string[] args)
> {
> StructOne s1 = new StructOne(1,"hello");
> s1.a = 2;
> s1.S = "world";
> s1.display();
> Console.WriteLine(s1.ToString());
> }
> }
>
>

[Jonathan Allen]

Lets say you write...

A = B

If they are classes, A points to the same object as B.
If they are structs, A becomes a copy of B.

Did you ever use "Type" in VB? If so, think of a struct as a UDT.

--
Jonathan Allen


"max caber" <maxcaber@yahoo.com> wrote in message
news:3bba361c$1@news.devx.com...
>
> I am having a hard time understanding the difference between a "struct"
and
> a "class". Please explain why and where you would use a "struct" instead
> of a "class". The following code demonstrates that structs can have
constructors,
> methods and propterties. Are they that different from classes that they
> are needed?
>
> public struct StructOne
> {
> public int a;
> string s;
>
> public StructOne(int a,string s)
> {
> this.a=a;
> this.s=s;
> }
> public void display()
> {
> Console.WriteLine(this.ToString());
> }
> public override String ToString()
> {
> return this.a + " : " + this.s;
> }
> public string S
> {
> set{s=value;}
> get{return this.s;}
> }
> }
>
> class ClientMain
> {
> static void Main(string[] args)
> {
> StructOne s1 = new StructOne(1,"hello");
> s1.a = 2;
> s1.S = "world";
> s1.display();
> Console.WriteLine(s1.ToString());
> }
> }
>
>

[KraKheD]

Max,

As Rob stated, structs are value types and classes are reference types. I
recall reading a piece of documentation which stated that you should use
structs ONLY when defining relatively simple entities. (This is directly
tied to the a struct being a value type.)

Obiviously, you will lose things like inheritence with structs as well.

Hope that helps.



"max caber" <maxcaber@yahoo.com> wrote:
>
>I am having a hard time understanding the difference between a "struct"
and
>a "class". Please explain why and where you would use a "struct" instead
>of a "class". The following code demonstrates that structs can have constructors,
>methods and propterties. Are they that different from classes that they
>are needed?
>
>public struct StructOne
> {
> public int a;
> string s;
>
> public StructOne(int a,string s)
> {
> this.a=a;
> this.s=s;
> }
> public void display()
> {
> Console.WriteLine(this.ToString());
> }
> public override String ToString()
> {
> return this.a + " : " + this.s;
> }
> public string S
> {
> set{s=value;}
> get{return this.s;}
> }
> }
>
>class ClientMain
> {
> static void Main(string[] args)
> {
> StructOne s1 = new StructOne(1,"hello");
> s1.a = 2;
> s1.S = "world";
> s1.display();
> Console.WriteLine(s1.ToString());
> }
> }
>
>

[Mikael]

"KraKheD" <S@S.com> wrote:

>Obiviously, you will lose things like inheritence with structs as well.

Can't you really have inheritence with structs in VB and C#? Why?

In C++ you have allways been able to inherit structs.

// Mikael

[Ted]

David A. Rothgery <drothgery@alum.wpi.edu> wrote:
>Mikael <mjs@nospam.beamex.com> wrote:
>>
>> "KraKheD" <S@S.com> wrote:
>>
>> >Obiviously, you will lose things like inheritence with structs as well.
>>
>> Can't you really have inheritence with structs in VB and C#? Why?
>>
>> In C++ you have allways been able to inherit structs.
>
>In C++, structs are just classes where the default access mode is
>public.
>
>This is not the case for .NET Value Types, which is to say C# structs
>and vb.NET Structures.


What does the access level have to do with inheritance? Is there something
in vb.net that disallows inheritance on those merits? Is there some construct
like "protected" in vb.net???

Thanks

[David A. Rothgery]

Mikael <mjs@nospam.beamex.com> wrote:
>
> "KraKheD" <S@S.com> wrote:
>
> >Obiviously, you will lose things like inheritence with structs as well.
>
> Can't you really have inheritence with structs in VB and C#? Why?
>
> In C++ you have allways been able to inherit structs.

In C++, structs are just classes where the default access mode is
public.

This is not the case for .NET Value Types, which is to say C# structs
and vb.NET Structures.

--
Dave Rothgery
Picking nits since 1976
drothgery@alum.wpi.edu
http://drothgery.editthispage.com

[Bob]

In article <3bba3c60$1@news.devx.com>, "Rob Teixeira" <RobTeixeira@@msn.com>
says...
>
>
> Yes, they are different. Structures are Value types and not Reference types.
>
> -Rob
>
Rob,

That reminds me, since Structures are value types, does that mean that every
time a method is invoked on a Structure, it gets boxed for the method
invocation? Or, better yet, under what circumstances does a Structure get
boxed?

Thanks,

Bob

[Rob Teixeira]

It's not the access level that prevents or allows the inheritance. It's the
fact that .NET does not treat structures as normal classes.

The protected access modifier is supported by VB.NET.

-Rob

"Ted" <TTarney@hotmail.com> wrote:
>
>What does the access level have to do with inheritance? Is there something
>in vb.net that disallows inheritance on those merits? Is there some construct
>like "protected" in vb.net???
>
>Thanks
>

[Rob Teixeira]

Bob <rainsleyno@bodyspamsolutions.com> wrote:
>
>Rob,
>
>That reminds me, since Structures are value types, does that mean that every

>time a method is invoked on a Structure, it gets boxed for the method
>invocation?

Bob,

When you define a structure in code, you are defining both the value type
itself and its associated boxed type. The reference/boxing behaviour depends
on the method.

Static methods on a structure are passed a managed reference to the value
type instance (managed pointer). The same static method on the boxed instance
is passed the object reference.

Instance methods on a structure also receive a managed reference to the value
type instance.

Virtual methods on a structure receive the boxed instance object reference.

> Or, better yet, under what circumstances does a Structure get
>boxed?

In C# and MVC++, you have a boxing and unboxing operator.
In VB, you will have to use the RuntimeHelpers.GetObjectValue method.
Treating a value type as an object will box it as well (such as passing a
value type to an object parameter).

-Rob

[Jonathan Allen]

> That reminds me, since Structures are value types, does that mean that
every
> time a method is invoked on a Structure, it gets boxed for the method
> invocation?

No, the CLR isn't that stupid. It just passes a pointer to the method call.
The fact that it points to the stack is irrelevant.

> Or, better yet, under what circumstances does a Structure get
> boxed?

A structure is boxed when you assign it to an Object variable.

Dim X as Integer, X2 as Integer, Y as Object, Y2 as Object
Function Zoom (ByRef Z as Integer)
Function Bar (ByVal Z as Integer)
Function Foo (Z as Object)

X2 = X //a copy is made
Y = X //this is boxing
X = Y //this is unboxing
Y = Y2 // a reference is made, just like any other object

Zoom(X) //a pointer to X is passed.
Bar(X) //a copy is made
Foo(X) //this is boxing
Foo(Y) //this isn't boxing because it was already boxed

--
Jonathan Allen


"Bob" <rainsleyno@bodyspamsolutions.com> wrote in message
news:MPG.1624d080a797179d98968a@news.devx.com...
> In article <3bba3c60$1@news.devx.com>, "Rob Teixeira"
<RobTeixeira@@msn.com>
> says...
> >
> >
> > Yes, they are different. Structures are Value types and not Reference
types.
> >
> > -Rob
> >
> Rob,
>
> That reminds me, since Structures are value types, does that mean that
every
> time a method is invoked on a Structure, it gets boxed for the method
> invocation? Or, better yet, under what circumstances does a Structure get
> boxed?
>
> Thanks,
>
> Bob

[Jonathan Allen]

> Static methods on a structure are passed a managed reference to the value
> type instance (managed pointer).

You can't say that. It depends entirely on the method signature. For
instance, Integer.Parse(~) doesn't have a value type instance to pass.


> Virtual methods on a structure receive the boxed instance object
reference.

What virtual methods? Structures cannot be inherited, so you can't create
your own virtual methods. As for the ones inherited from Object, I'm sure
the CLR is smart enough not to need boxing to access them.

--
Jonathan Allen


"Rob Teixeira" <RobTeixeira@@msn.com> wrote in message
news:3bbb33f2$1@news.devx.com...
>
> Bob <rainsleyno@bodyspamsolutions.com> wrote:
> >
> >Rob,
> >
> >That reminds me, since Structures are value types, does that mean that
every
>
> >time a method is invoked on a Structure, it gets boxed for the method
> >invocation?
>
> Bob,
>
> When you define a structure in code, you are defining both the value type
> itself and its associated boxed type. The reference/boxing behaviour
depends
> on the method.
>
> Static methods on a structure are passed a managed reference to the value
> type instance (managed pointer). The same static method on the boxed
instance
> is passed the object reference.
>
> Instance methods on a structure also receive a managed reference to the
value
> type instance.
>
> Virtual methods on a structure receive the boxed instance object
reference.
>
> > Or, better yet, under what circumstances does a Structure get
> >boxed?
>
> In C# and MVC++, you have a boxing and unboxing operator.
> In VB, you will have to use the RuntimeHelpers.GetObjectValue method.
> Treating a value type as an object will box it as well (such as passing a
> value type to an object parameter).
>
> -Rob

[Jonathan Allen]

> Can't you really have inheritence with structs in VB and C#? Why?


Structures are stored on the stack. That means you have to know EXACTLY how
big they are ahead of time.

Structure ComplexInteger Inherits Integer
Public IValue as Integer //imaginary part
End Structure

Dim A as Integer
A = New ComplexInteger

When the stack was built, it allocated enough room for an Integer. I just
tried to put something twice as big on it, so where does it find the space?

--
Jonathan Allen


"Mikael" <mjs@nospam.beamex.com> wrote in message
news:3bbab31e$1@news.devx.com...
>
> "KraKheD" <S@S.com> wrote:
>
> >Obiviously, you will lose things like inheritence with structs as well.
>
> Can't you really have inheritence with structs in VB and C#? Why?
>
> In C++ you have allways been able to inherit structs.
>
> // Mikael
>

[Rob Teixeira]

"Jonathan Allen" <greywolf@cts.com> wrote:
>
>You can't say that. It depends entirely on the method signature. For
>instance, Integer.Parse(~) doesn't have a value type instance to pass.
>

That should read non-static.

>What virtual methods? Structures cannot be inherited, so you can't create
>your own virtual methods.

The boxed type can have virtual methods.

>As for the ones inherited from Object, I'm sure
>the CLR is smart enough not to need boxing to access them.

The CLI states that the in this case, as opposed to non-virtual instance
methods, the object reference, not the managed pointer to the value type
storage, is used.

-Rob

[Rob Teixeira]

"Jonathan Allen" <greywolf@cts.com> wrote:
>
>Structures are stored on the stack. That means you have to know EXACTLY
how
>big they are ahead of time.
>

Somebody might correct me on this, but i don't think this is always the case.

The CLI states that value types "don't need to be allocated on the heap",
not that they "are stored on the stack".

But you are correct in inferring that one of the big differences is that
in contrast, class instance storage is always on the heap.

-Rob