Structures vs. Classes

  • Thread starter Thread starter thomasfarrow
  • Start date Start date
T

thomasfarrow

At work, our development team has a development standards document that

insists Structures should never be used. I'm looking to change this
standard but need a suitable argument in order to make the change. I
know that Structures are value types, sit on the stack, and are
generally more efficient to manipulate than reference types (i.e.
Classes). Structures cannot use inheritance, the finalize method or
default constructors. Can anyone think of a situation where using
Structures is more suitable than using Classes?
 
At work, our development team has a development standards document
that

insists Structures should never be used. I'm looking to change this
standard but need a suitable argument in order to make the change. I
know that Structures are value types, sit on the stack, and are
generally more efficient to manipulate than reference types (i.e.
Classes). Structures cannot use inheritance, the finalize method or
default constructors. Can anyone think of a situation where using
Structures is more suitable than using Classes?
Click to expand...

Structures should be used ONLY for very small value types, so if the
struct refers to an object, it's likely not a valid candidate to be a
struct.

Structs have the disadvantage that if you store them in an arraylist
or List<T>, manipulating them isn't as convenient as you'd think:

myList[index].MyProperty = value;
won't work, as you're manipulating the value you get from the indexer,
not the value INSIDE the list. This can lead to bugs you only encouter
at runtime, and therefore most people opt for classes instead, which is
in general the right thing to do.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
 
The only time I use structures is when two or more related simple data types
(int, boolean, string, etc.) need to be grouped together. Even in this
case, I tend to use classes because I can easily change a public property
into a private property with a public property SET/GET block of code that
cleans up the data. Also, structures don't have a constructor to allow for
default value setting.

Mike Ober.
 
Pros:
1. Greater perf as it takes less time to allocate memory on the stack that
the heap - this is miniscule, so don't use this as a reason, unless other
perf tweaks have failed and you are at the end of your rope (even then, I
might hang myself before switching to a struct system)
2. More deterministic clean up. The stack is guaranteed to die when the
appDomain is unloaded, while the heap, technically, can live on - this is a
minor benefit in most cases, as you are not in control of memory either way

Cons
1. Cannot code the default constructor. If you need to spin up an object
with some instantiation work, you have to have at least one parameter. This
has to do with a default construct already hard wired.
2. When you use interfaces, the struct is boxed and you have to explicitly
unbox it if you desire to use it as a value type. This means you lose one of
the benefits of structs.

Implications (neither pro or con):
1. Structs are passed, as parameters, by value. This means a new “object†is
created internally. Classes are passed by reference. Depending on your
system, this can be a big deal.

Overall, structs are good for small "collections" of value types
(implemented as properties or fields), when you do not need to add methods or
adhere to an interface, like a User Defined Type (UDF), and when passing by
reference does not make sense.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************
 
Cowboy (Gregory A. Beamer) - MVP <[email protected]>
wrote:

Implications (neither pro or con):
1. Structs are passed, as parameters, by value. This means a new ?object? is
created internally. Classes are passed by reference. Depending on your
system, this can be a big deal.
Click to expand...

Just for future reference - classes (objects) are *not* passed by
references by default. A *reference* is passed *by value*. There's a
big difference.

See http://www.pobox.com/~skeet/csharp/parameters.html

(I'm picky about this because I've seen it confuse people who genuinely
understand the difference between pass-by-reference and pass-by-value
semantics. They hear that "objects are passed by reference" and expect
things to work which don't.)
 
At work, our development team has a development standards document that
insists Structures should never be used. I'm looking to change this
standard but need a suitable argument in order to make the change. I
know that Structures are value types, sit on the stack
Click to expand...

Small point - structures don't always sit on the stack. They sit
wherever the variable lives (for variables). See
http://www.pobox.com/~skeet/csharp/memory.html

I would suggest that you don't bother trying to change the standard
until you've got a really good candidate for a value type. They do
exist, but they're few and far between in my experience.
 
Like someone else mentioned,

I only use structures when I have many (> 1000 instances) of the same
struct to create, and even then only when there is only one or two
values that I need to place into the struct (like two strings, or an
int and a string)

I rarely use structs, but sometimes I opt for them if I don't need a
constructor or any other fancy manipulation of the structs.
 
Always keeping us honest, Jon! While this does seem picky, I have
(reluctantly) benefitted from your "nagging" in that it has forced me to be
more accurate, and to study and understand things on a deeper level. For
example, I have made a thorough study of .Net memory management, and am
highly unlikely to confuse what goes on the stack and what goes on the heap
ever again! From time to time, this understanding has proven invaluable to
me personally.

;-)

--

Kevin Spencer
Microsoft MVP
..Net Developer

Presuming that God is "only an idea" -
Ideas exist.
Therefore, God exists.
 
Back
Top