Why are some types implemented as struct?

MC · Jul 28 '08, 04:35 PM

Re: Why are some types implemented as struct?

>I know the basic differences between a struct and a class, but

apparently not good enough to know why some types/concepts are
implemented as struct whereas most types are implemented as class.
For example, why is DateTime implemented as a struct? Why is BitArray
implemented as a class, but BitVector32 a struct?
>
In general, in OO design, how do we determine if we should use struct
or class?

I think that, in general, structs are for small things that use a fixed
amount of memory.

**tal_mcmahon** · Jul 28 '08, 06:15 PM

Re: Why are some types implemented as struct?

On Jul 28, 10:33 am, Author <gnewsgr...@gma il.comwrote:

I know the basic differences between a struct and a class, but
apparently not good enough to know why some types/concepts are
implemented as struct whereas most types are implemented as class.
For example, why is DateTime implemented as a struct? Why is BitArray
implemented as a class, but BitVector32 a struct?
>
In general, in OO design, how do we determine if we should use struct
or class?

Struct are placed in memory on the stack, therefore faster and do not
need to be cleaned up with garbage collection. Structs cannot be
extended and cannot extend anything else.

Classes Are on the heap, must be cleaned up and can be extended or
extend.

For most of us, a big "So what?"

I am assuming the choice af struct vs class is something that MS
thinks a lot more about in a framework than the common code grunt and
it comes down to first, performance and then to Symmetry in the code.

thats my take on it.

Tal

**Peter Morris** · Jul 28 '08, 06:25 PM

Re: Why are some types implemented as struct?

Nearly every time I have designed something as a struct I have later
discovered I need to be able to change the values in it and ended up
converting it to a class, so now I just don't bother with them any more.

**Fredo** · Jul 28 '08, 06:55 PM

Re: Why are some types implemented as struct?

"Peter Morris" <mrpmorrisNO@SP AMgmail.comwrot e in message
news:%23otio6N8 IHA.2348@TK2MSF TNGP06.phx.gbl. ..

Nearly every time I have designed something as a struct I have later
discovered I need to be able to change the values in it and ended up
converting it to a class, so now I just don't bother with them any more.
>

You can change values in a struct as easily as you can in a class. In fact,
in a lot of ways, you can make a struct act like a class. You can create
properties that you can get and set, just like a class. You can create
methods, you can make field members public. So I'm not really sure what you
mean.

**Author** · Jul 28 '08, 07:35 PM

Re: Why are some types implemented as struct?

On Jul 28, 12:23 pm, "MC" <for.address.l. ..@www.ai.uga.e du.slash.mc>
wrote:

I know the basic differences between a struct and a class, but
apparently not good enough to know why some types/concepts are
implemented as struct whereas most types are implemented as class.
For example, why is DateTime implemented as a struct? Why is BitArray
implemented as a class, but BitVector32 a struct?

>

In general, in OO design, how do we determine if we should use struct
or class?

>
I think that, in general, structs are for small things that use a fixed
amount of memory.

Hmm, sounds reasonable, at least with regard to BitArray (resizable)
and BitVector32 (not resizable). But is this the only possible reason
that some types are implemented as struct and others class?

I've read the other responses of my question, but they seem to be off-
topic. I would like to hear some guruish comment about my question.

**Peter Duniho** · Jul 28 '08, 09:15 PM

Re: Why are some types implemented as struct?

On Mon, 28 Jul 2008 11:53:40 -0700, Fredo <fredo@hotmail. comwrote:

"Peter Morris" <mrpmorrisNO@SP AMgmail.comwrot e in message
news:%23otio6N8 IHA.2348@TK2MSF TNGP06.phx.gbl. ..

>Nearly every time I have designed something as a struct I have later
>discovered I need to be able to change the values in it and ended up
>converting it to a class, so now I just don't bother with them any more.
>>

>
You can change values in a struct as easily as you can in a class.

Well, yes and no.

There are some serious problems with making a struct mutable. The fact
that structs are _copied_ rather than references leads to code that either
doesn't work as expected (you think you've changed an instance but have
only changed a copy of an instance), or just doesn't compile, or is more
inconvenient than it could or should be.

Pete

**Peter Duniho** · Jul 28 '08, 09:15 PM

Re: Why are some types implemented as struct?

On Mon, 28 Jul 2008 11:12:39 -0700, tal_mcmahon <tal_mcmahon@ho tmail.com>
wrote:

Struct are placed in memory on the stack,

No. This is a common, but serious misconception.

Structs are "value types". That means that the storage for the type is
allocated where the variable itself is stored. But only local variables
wind up on the stack. A struct used in a class, or in an array, or
anything else that is itself allocated on the heap will wind up on the
heap itself.

therefore faster and do not
need to be cleaned up with garbage collection.

Structs need to be collected when boxed. They also wind up collected
implicitly when they are part of a class that is collected.

In fact, if a struct winds up boxed on a regular basis that will suggest
that the data structure should have been a class after all.

Pete

**Peter Webb** · Jul 29 '08, 11:45 AM

Re: Why are some types implemented as struct?

"Author" <gnewsgroup@gma il.comwrote in message
news:00f244f5-64c2-4c98-b45f-c9cc33d6df86@f6 3g2000hsf.googl egroups.com...
On Jul 28, 12:23 pm, "MC" <for.address.l. ..@www.ai.uga.e du.slash.mc>
wrote:

I know the basic differences between a struct and a class, but
apparently not good enough to know why some types/concepts are
implemented as struct whereas most types are implemented as class.
For example, why is DateTime implemented as a struct? Why is BitArray
implemented as a class, but BitVector32 a struct?

>

In general, in OO design, how do we determine if we should use struct
or class?

>
I think that, in general, structs are for small things that use a fixed
amount of memory.

Hmm, sounds reasonable, at least with regard to BitArray (resizable)
and BitVector32 (not resizable). But is this the only possible reason
that some types are implemented as struct and others class?

I've read the other responses of my question, but they seem to be off-
topic. I would like to hear some guruish comment about my question.

*************** **************
I'm only a beginner myself, but nobody has mentioned that classes are
inheritable, whereas structs are not. If you are looking at this from an OOP
perspective, this is a huge difference.

**Peter Morris** · Jul 29 '08, 01:35 PM

Re: Why are some types implemented as struct?

To be honest I don't even remember the problems I had, I just remember that
every time I have used them I have ended up switching to classes so now I
don't bother.

Pete

**Pavel Minaev** · Jul 29 '08, 02:35 PM

Re: Why are some types implemented as struct?

On Jul 28, 7:33 pm, Author <gnewsgr...@gma il.comwrote:

In general, in OO design, how do we determine if we should use struct
or class?

A few distinguishing traits:

1) It is data-centric, not behavior-centric - e.g. Point is just a
tuple of two ints, Person is an entity with encapsulated operations.
Most methods on structs are just helpers to manipulate data, and could
usually be refactored as external methods. Most methods on classes
should encapsulate business logic related to entities those classes
model.

2) It has no identity - two structs are equal if the data within is
the same; for two structs with the same data, there is no way to
distinguish them, and using one in place of the other should give
identical results for any operation. C# enforces this by requiring
structs to define at least one field (since two identityless objects
which don't have data cannot be distinguished at all, so the result is
effectively a singleton). For example, if you get a Point with X=2 and
Y=3 from the first method, it is guaranteed that whether you pass that
same Point on to the second method, or create your own new Point with
the same values of X and Y and then pass that to the second method,
the actions performed by the second method will be exactly the same.
On the other hand, if you have two different Person instances, they
typically refer to two different people, even if their names (and
other data) match, so passing one instead of another to a business
method will do a different thing. In C#, this manifests itself in the
fact that classes have operator== which compares references (i.e. does
an identity comparison), and default implementation of Equals() for
classes also does reference comparison, while for structs Equals()
compares values of all fields, and there is no way to do a reference
comparison.

3) It is atomic with respect to updates - you cannot take an existing
Point and change just the X coordinate - the result would always be a
new Point. In C# terms, this means that structs are immutable (this
isn't enforced by the compiler, but is strongly recommended to follow
the practice nonetheless).

Simply put, the design difference between a struct and a class is the
difference between raw data (tuple, record, etc) and an entity. The
line can be blurry sometimes, but usually it is fairly obvious for
every specific case.

Of course, in real world, decision on using class vs struct is often
made for performance reasons - a good example is List<T>.Enumera tor,
which is a struct, though it doesn't really fit the definition above.

**Fredo** · Jul 29 '08, 10:15 PM

Re: Why are some types implemented as struct?

"Peter Duniho" <NpOeStPeAdM@nn owslpianmk.comw rote in message
news:op.ue0sxin 48jd0ej@petes-computer.local. ..

On Mon, 28 Jul 2008 11:53:40 -0700, Fredo <fredo@hotmail. comwrote:
>

>"Peter Morris" <mrpmorrisNO@SP AMgmail.comwrot e in message
>news:%23otio6N 8IHA.2348@TK2MS FTNGP06.phx.gbl ...

>>Nearly every time I have designed something as a struct I have later
>>discovered I need to be able to change the values in it and ended up
>>converting it to a class, so now I just don't bother with them any more.
>>>

>>
>You can change values in a struct as easily as you can in a class.

>
Well, yes and no.
>
There are some serious problems with making a struct mutable. The fact
that structs are _copied_ rather than references leads to code that either
doesn't work as expected (you think you've changed an instance but have
only changed a copy of an instance), or just doesn't compile, or is more
inconvenient than it could or should be.
>
Pete

Pete,

You're absolutely correct. I guess part of it is mentality.

I generally reserve structs for things that I think of as "non-trivial
datatypes". For example, point, size, rect, vector (mathematical, not in the
array sense), and so forth, are little more than data types that are
slightly more complex than the basic data types. So the fact that they pass
by value instead of by reference, just like the basic data types, makes
sense.

They can also be useful in the plain old C sense of struct (a collection of
related variables), though I generally go with a class in that case.

Pete

**Peter Duniho** · Jul 30 '08, 06:35 AM

Re: Why are some types implemented as struct?

On Tue, 29 Jul 2008 07:31:58 -0700, Pavel Minaev <int19h@gmail.c omwrote:

On Jul 28, 7:33Â pm, Author <gnewsgr...@gma il.comwrote:

>In general, in OO design, how do we determine if we should use struct
>or class?

>
A few distinguishing traits:
>
1) It is data-centric, not behavior-centric [...]
>
2) It has no identity - two structs are equal if the data within is
the same [...]
>
3) It is atomic with respect to updates [...]

Of course, all of the above three apply to the String type, which is _not_
a struct.

All due respect, I think you missed one of the most important aspects of a
struct: it's usually something small, so that copying it around isn't
costly. And I think that there are a number of examples of classes that
would fit your three criteria but still are better as classes than structs.

Pete

Why are some types implemented as struct?

Why are some types implemented as struct?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment