Why are some types implemented as struct?
Author
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?
MC
I think that, in general, structs are for small things that use a fixed
amount of memory.
tal_mcmahon
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
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
news:%23otio6N...@TK2MSFTNGP06.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
wrote:
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
> "Peter Morris" <mrpmo...@SPAMgmail.com> wrote in message
> news:%23otio6N...@TK2MSFTNGP06.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
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
"Author" <gnews...@gmail.com> wrote in message
news:00f244f5-64c2-4c98...@f63g2000hsf.googlegroups.com...
*****************************
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
every time I have used them I have ended up switching to classes so now I
don't bother.
Pete
Pavel Minaev
> 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>.Enumerator,
which is a struct, though it doesn't really fit the definition above.
Author
Finally, an in-depth comment. Thanks a lot. One has to have a very
strong analytical mind about objects/abstract concepts of the real
world in order to be a good OO designer.
Fredo
"Peter Duniho" <NpOeS...@nnowslpianmk.com> wrote in message
news:op.ue0sx...@petes-computer.local...
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
> On Jul 28, 7:33 pm, Author <gnewsgr...@gmail.com> wrote:
>> 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