Struct vs Class

[JohnGoogle]

Hi,

Newbie question...

After a recent article in VSJ I had a go at implementing a Fraction
class to aid my understanding of operator overloading. After a previous
message someone suggested that I implement it as a struct rather than a
class which I did and all worked OK.

The simplest declaration for the struct is:

public struct Fraction
{
private Int32 _numerator;
private Int32 _denominator;

public Int32 numerator
{
get { return _numerator; }
}

public Int32 denominator
{
get { return _denominator; }
}

public Fraction(Int32 numerator)
{
this._numerator = numerator;
this._denominat or = 1;
}

public Fraction(Int32 numerator, Int32 denominator)
{
this._numerator = numerator;
this._denominat or = denominator;
if (denominator < 1)
throw new ArgumentExcepti on("Fraction denominator value
'" + denominator.ToS tring() + "' is invalid.");
}

// All other declarations follow (for overloads of
+,-,*,/,++,--,>,<, etc).
}
As you can see, it is essential that the denominator must be 1 or more.
As it was originally a class, the constructors ensured that the
denominator was >= 1. Alos, the numerator and denominator values are
read only as they can only be modified by operators such as +,-,++,*,/
etc (not shown).

However, during my testing I realised that, as a struct, it is possible
to declare a struct which is initialised to 0 so the denominator
becomes illegal.

I've found that you cannot declare a parameterless construction such
as:

public struct Fraction
{
private Int32 _numerator;
private Int32 _denominator;
....
public Fraction()
{
this._numerator = 0;
this._denominat or = 1;
}
....
}

This gives a compiler error: 'Structs cannot contain explicit
parameterless constructors'.
Also, you cannot initialise the fields of a struct such as:

public struct Fraction
{
private Int32 _numerator;
private Int32 _denominator = 1;
....
}

This gives a compilation error: '_denominator': cannot have instance
field initializers in structs'.
Is there any way to force a field of a struct to be initialised to a
non zero value?

If not, I'll go back to implementing it as a class.

TIA,

John.

[Dave Sexton]

Hi,

You can't prevent the initialization of an instance of a struct with default
values. You'll always be able to code: Fraction fr = new Fraction(),
regardless of the constructors that you define.

If you decide to stick with a struct, don't forget to override Equals and
GetHashCode as well. And make sure that their return values are deterministic
and consistent with each other.

--
Dave Sexton

<Jo********@hot mail.co.ukwrote in message
news:11******** **************@ k70g2000cwa.goo glegroups.com.. .

Hi,

Newbie question...

After a recent article in VSJ I had a go at implementing a Fraction
class to aid my understanding of operator overloading. After a previous
message someone suggested that I implement it as a struct rather than a
class which I did and all worked OK.

The simplest declaration for the struct is:

public struct Fraction
{
private Int32 _numerator;
private Int32 _denominator;

public Int32 numerator
{
get { return _numerator; }
}

public Int32 denominator
{
get { return _denominator; }
}

public Fraction(Int32 numerator)
{
this._numerator = numerator;
this._denominat or = 1;
}

public Fraction(Int32 numerator, Int32 denominator)
{
this._numerator = numerator;
this._denominat or = denominator;
if (denominator < 1)
throw new ArgumentExcepti on("Fraction denominator value
'" + denominator.ToS tring() + "' is invalid.");
}

// All other declarations follow (for overloads of
+,-,*,/,++,--,>,<, etc).
}
As you can see, it is essential that the denominator must be 1 or more.
As it was originally a class, the constructors ensured that the
denominator was >= 1. Alos, the numerator and denominator values are
read only as they can only be modified by operators such as +,-,++,*,/
etc (not shown).

However, during my testing I realised that, as a struct, it is possible
to declare a struct which is initialised to 0 so the denominator
becomes illegal.

I've found that you cannot declare a parameterless construction such
as:

public struct Fraction
{
private Int32 _numerator;
private Int32 _denominator;
....
public Fraction()
{
this._numerator = 0;
this._denominat or = 1;
}
....
}

This gives a compiler error: 'Structs cannot contain explicit
parameterless constructors'.
Also, you cannot initialise the fields of a struct such as:

public struct Fraction
{
private Int32 _numerator;
private Int32 _denominator = 1;
....
}

This gives a compilation error: '_denominator': cannot have instance
field initializers in structs'.
Is there any way to force a field of a struct to be initialised to a
non zero value?

If not, I'll go back to implementing it as a class.

TIA,

John.

[JohnGoogle]

Thanks Dave,

I do override Equals and GetHashcode already. I guess I'll change it
back to a class. Thank you for you feedback. From what I had read, I
thought this was the case.

As a newbie, I'm interested in how much boxing / unboxing will be going
on when I define a struct as opposed to a class. I've just got Jeffrey
Richter's CLR via C# which seems to show me how to determine this via
the IL Disassembler. Some investigations to be done!

Thanks.

John.

[Jon Skeet [C# MVP]]

<Jo********@hot mail.co.ukwrote :

<snip>

Is there any way to force a field of a struct to be initialised to a
non zero value?

No - and you'll always end up with the zero value if you create, say,
an array of the struct type.

If not, I'll go back to implementing it as a class.

I wouldn't make that the most important influence in your decision.
It's easy to ensure that the struct is initialised appropriately
wherever it's actually used. Think of a zero value for a struct as a
sort of equivalent (in this particular case) to a null value for a
reference type. Just as you could do:

FractionStruct x = new FractionStruct( ); // x is useless at the moment

you could do:

FractionClass y = null; // y is just as useless at the moment
A fraction still feels more like a value type than a reference type to
me.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Bruce Wood]

Jo********@hotm ail.co.uk wrote:

Thanks Dave,

I do override Equals and GetHashcode already. I guess I'll change it
back to a class. Thank you for you feedback. From what I had read, I
thought this was the case.

As a newbie, I'm interested in how much boxing / unboxing will be going
on when I define a struct as opposed to a class. I've just got Jeffrey
Richter's CLR via C# which seems to show me how to determine this via
the IL Disassembler. Some investigations to be done!

I, too, created a Fraction class for use in our company. Trust me:
don't make it a class. Simply assign meaning to "everything zero". It's
"essential" that the denominator be greater than zero only if you say
it's essential; you're writing the code, so you can make any
assumptions you want.

Simply write the internals so that denominator and numerator both zero
means "zero". Yes, it means more checks inside your code, but as I
said, trust me: making this a class will make it much less useful and
make it act much less intuitively. It should be a struct.

[Ryan]

You could make the _denominator field nullable and check for null in
the property:

public struct Fraction {
private Int32? _denominator;

[...]
public Int32 Denominator {
get{ if ( _denominator == null ) return 1; else return
(Int32)_denomin ator; }
}

[...]
}

Regards
,
Ryan

On Oct 28, 4:43 pm, JohnGoo...@hotm ail.co.uk wrote:

Hi,

Newbie question...

After a recent article in VSJ I had a go at implementing a Fraction
class to aid my understanding of operator overloading. After a previous
message someone suggested that I implement it as a struct rather than a
class which I did and all worked OK.

The simplest declaration for the struct is:

public struct Fraction
{
private Int32 _numerator;
private Int32 _denominator;

public Int32 numerator
{
get { return _numerator; }
}

public Int32 denominator
{
get { return _denominator; }
}

public Fraction(Int32 numerator)
{
this._numerator = numerator;
this._denominat or = 1;
}

public Fraction(Int32 numerator, Int32 denominator)
{
this._numerator = numerator;
this._denominat or = denominator;
if (denominator < 1)
throw new ArgumentExcepti on("Fraction denominator value
'" + denominator.ToS tring() + "' is invalid.");
}

// All other declarations follow (for overloads of
+,-,*,/,++,--,>,<, etc).
}

As you can see, it is essential that the denominator must be 1 or more.
As it was originally a class, the constructors ensured that the
denominator was >= 1. Alos, the numerator and denominator values are
read only as they can only be modified by operators such as +,-,++,*,/
etc (not shown).

However, during my testing I realised that, as a struct, it is possible
to declare a struct which is initialised to 0 so the denominator
becomes illegal.

I've found that you cannot declare a parameterless construction such
as:

public struct Fraction
{
private Int32 _numerator;
private Int32 _denominator;
....
public Fraction()
{
this._numerator = 0;
this._denominat or = 1;
}
....
}

This gives a compiler error: 'Structs cannot contain explicit
parameterless constructors'.

Also, you cannot initialise the fields of a struct such as:

public struct Fraction
{
private Int32 _numerator;
private Int32 _denominator = 1;
....
}

This gives a compilation error: '_denominator': cannot have instance
field initializers in structs'.

Is there any way to force a field of a struct to be initialised to a
non zero value?

If not, I'll go back to implementing it as a class.

TIA,

John.

[Martin Z]

In general you want a way to flag the object as "uninitiali zed" - while
there are numerous clever ways to do it, ultimately the simplest
approach is to include a boolean. It's tempting to use a nullable
type, but afaik nullables are reference types, thus eliminating the
niceties using a struct. Structs work so much better when only
containing values.

As such, include a private boolean "isDenominatorI initialized" - and
use

public Int32 Denominator {
get{ if (isDenominatorI initialized == false ) return 1; else
return (Int32)_denomin ator; }
private set {isDenominatorI nitialized = true; _denominator =
value; }
}

And then use the private set whenever you (internally) assign to the
denominator. This assumes 2.0 where you can have differing access to
get/set attributes. This should perform better than the nullable
approach.

Ryan wrote:

You could make the _denominator field nullable and check for null in
the property:

public struct Fraction {
private Int32? _denominator;

[...]
public Int32 Denominator {
get{ if ( _denominator == null ) return 1; else return
(Int32)_denomin ator; }
}

[...]
}

Regards
,
Ryan

On Oct 28, 4:43 pm, JohnGoo...@hotm ail.co.uk wrote:

Hi,

Newbie question...

After a recent article in VSJ I had a go at implementing a Fraction
class to aid my understanding of operator overloading. After a previous
message someone suggested that I implement it as a struct rather than a
class which I did and all worked OK.

The simplest declaration for the struct is:

public struct Fraction
{
private Int32 _numerator;
private Int32 _denominator;

public Int32 numerator
{
get { return _numerator; }
}

public Int32 denominator
{
get { return _denominator; }
}

public Fraction(Int32 numerator)
{
this._numerator = numerator;
this._denominat or = 1;
}

public Fraction(Int32 numerator, Int32 denominator)
{
this._numerator = numerator;
this._denominat or = denominator;
if (denominator < 1)
throw new ArgumentExcepti on("Fraction denominator value
'" + denominator.ToS tring() + "' is invalid.");
}

// All other declarations follow (for overloads of
+,-,*,/,++,--,>,<, etc).
}

As you can see, it is essential that the denominator must be 1 or more.
As it was originally a class, the constructors ensured that the
denominator was >= 1. Alos, the numerator and denominator values are
read only as they can only be modified by operators such as +,-,++,*,/
etc (not shown).

However, during my testing I realised that, as a struct, it is possible
to declare a struct which is initialised to 0 so the denominator
becomes illegal.

I've found that you cannot declare a parameterless construction such
as:

public struct Fraction
{
private Int32 _numerator;
private Int32 _denominator;
....
public Fraction()
{
this._numerator = 0;
this._denominat or = 1;
}
....
}

This gives a compiler error: 'Structs cannot contain explicit
parameterless constructors'.

Also, you cannot initialise the fields of a struct such as:

public struct Fraction
{
private Int32 _numerator;
private Int32 _denominator = 1;
....
}

This gives a compilation error: '_denominator': cannot have instance
field initializers in structs'.

Is there any way to force a field of a struct to be initialised to a
non zero value?

If not, I'll go back to implementing it as a class.

TIA,

John.

[Martin Z]

Bruce, My understanding is that, if designed to be entirely immutable
and containing no events, then there is almost no visible difference
between a class and a struct. The struct is primarily a
speed-optimization - access to stack-variables is much faster. Hence,
structs should only contain other valuetypes.

Bruce Wood wrote:

Jo********@hotm ail.co.uk wrote:

Thanks Dave,

I do override Equals and GetHashcode already. I guess I'll change it
back to a class. Thank you for you feedback. From what I had read, I
thought this was the case.

As a newbie, I'm interested in how much boxing / unboxing will be going
on when I define a struct as opposed to a class. I've just got Jeffrey
Richter's CLR via C# which seems to show me how to determine this via
the IL Disassembler. Some investigations to be done!

I, too, created a Fraction class for use in our company. Trust me:
don't make it a class. Simply assign meaning to "everything zero". It's
"essential" that the denominator be greater than zero only if you say
it's essential; you're writing the code, so you can make any
assumptions you want.

Simply write the internals so that denominator and numerator both zero
means "zero". Yes, it means more checks inside your code, but as I
said, trust me: making this a class will make it much less useful and
make it act much less intuitively. It should be a struct.

[Dave Sexton]

Hi Martin,

The struct is primarily a
speed-optimization - access to stack-variables is much faster. Hence,
structs should only contain other valuetypes.

But values can be stored on the heap as well.

Check out this article by Jon Skeet:
http://www.yoda.arachsys.com/csharp/memory.html

Structs that have private fields that reference objects simply store the
reference with the rest of the structure. Memory-wise, it's just like storing
Int32, AFAIK.

A value type is meant to be just that - a value. Values are not meant to be
tangible objects - like paper - they are meant to represent a value that you
can assign to an object - like worth (money). Therefore, it makes sense to me
that values are stored in-line with the objects that contain them, or on the
stack if that's where they are placed. They stay with their container because
they only have value, not presence.

I ask myself the following question when choosing between a struct or class
definition:

When an instance is used as a hash key, should the corresponding value in a
hash table be accessible by value or by reference only?

In other words, will I need the reference of the entity in order to retrieve
the keyed value at a later time, or just the value?

It's usually obvious whether to use a struct or a class from there, even if I
don't plan on using any instances to key a hash table. I never take into
consideration whether the struct will contain references, however I don't
think I've ever created a struct that had references anyway - so I might agree
with you after all, but for a different reason :)

--
Dave Sexton

"Martin Z" <ma***********@ gmail.comwrote in message
news:11******** ************@k7 0g2000cwa.googl egroups.com...

Bruce, My understanding is that, if designed to be entirely immutable
and containing no events, then there is almost no visible difference
between a class and a struct. The struct is primarily a
speed-optimization - access to stack-variables is much faster. Hence,
structs should only contain other valuetypes.

Bruce Wood wrote:

>Jo********@hotm ail.co.uk wrote:

Thanks Dave,

I do override Equals and GetHashcode already. I guess I'll change it
back to a class. Thank you for you feedback. From what I had read, I
thought this was the case.

As a newbie, I'm interested in how much boxing / unboxing will be going
on when I define a struct as opposed to a class. I've just got Jeffrey
Richter's CLR via C# which seems to show me how to determine this via
the IL Disassembler. Some investigations to be done!

I, too, created a Fraction class for use in our company. Trust me:
don't make it a class. Simply assign meaning to "everything zero". It's
"essential" that the denominator be greater than zero only if you say
it's essential; you're writing the code, so you can make any
assumptions you want.

Simply write the internals so that denominator and numerator both zero
means "zero". Yes, it means more checks inside your code, but as I
said, trust me: making this a class will make it much less useful and
make it act much less intuitively. It should be a struct.

[Bruce Wood]

Martin Z wrote:

afaik nullables are reference types

Nope. From the MSDN doc:

http://msdn2.microsoft.com/en-us/library/1t3y8s4s.aspx

"Nullable types are instances of the System.Nullable struct."

Nullable types are value types, not reference types. They contain a
boolean flag indicating whether they are null or not, and space for the
value if they are not null.