On Fri, 30 May 2008 23:58:11 -0700, Ray Cassick
[quoted text, click to view]

Actually, it's worse than that. They say you should be _smaller_ than 16
bytes. 15 bytes is okay, 16 bytes is not. :)

I doubt that there's any specific performance threshold related to that
size. 16 bytes happens to be the size of a 32-bit Rectangle structure and
I'd guess someone just felt that's about as big a struct should get. And
then of course mis-worded the documentation in a way that suggests that
the Rectangle struct is actually too large. :)

Anyway, I would not treat the rule as an absolute. However, I would tend
to agree with it that if you find yourself making a struct much larger
than that, you may want to consider just switching to a class. Not
because of a specific performance issue, but because the size of the data
structure is somewhat correlated to the complexity, and structs really
ought to be semantically simple (as in the other suggestion on that page
that your struct should represent something that is logically just one
"thing").

I have been investigating this subject a bit and ran across this gem in
MSDN:

http://msdn.microsoft.com/en-us/library/ms229017(VS.80).aspx

This seems to specifically state that structures should not be any longer
that 16 bytes in size. Seems a bit limiting to me since I can hit that limit
by this:

Public Structure MyStruct
Dim field1 as ULong
Dim field2 as ULong
Dim field3 as ULong

End Structure

I am assuming that they have a good reason for saying this but I have looked
everywhere and cant seem to locate it. Can someone comment as to why this is
the case? I am assuming is has something to do with memory allocation on the
stack versus the heap but I would love to locate a good definitive answer...

Thanks for any pointers...

[quoted text, click to view]

Thanks for the response...

Yeah, I caught that bit about needing to be smaller than 16 Bytes too.
Chalked it up to an 'oops' in wording there.

16 bytes just seemed really small. I use structures a lot anytime I need to
pass data across functional boundaries but don't need to give it much
functionality that would require a class type structure. Like if I want to
just write out a series of records to a file I will build the record
structure, populate it and then write it out. Sometimes just writing out to
a stream using a structure is so much simpler than serializing something,
especially if I just need it written out to something simple for consumption
in another app. XML is good but you can cross the line and just induce a ton
of overhead if you are not careful.

I was just worried that by creating structures too large I may be inducing a
performance hit if there was some magic limit between being stored on the
stack vs. the heap that I was not aware of.

Thanks again.

On Sat, 31 May 2008 19:03:37 -0700, Ray Cassick
[quoted text, click to view]

IMHO, the more often you "cross functional boundaries", the more a class
becomes more appropriate than a struct.

Size of the object isn't the only factor. There are fundamental
differences in the way that the data structures are used. Structs are
value types and as such, unless they are boxed (which carries its own
penalty), every time you pass a struct from one place to the other, you
are copying the entire struct. A class is a reference type, and is passed
simply by copying the reference to the instance, not all of the data.

(Yes, you could always pass by reference, but that's abusing the language
and if nothing else adds a pointless architectural requirement on any
method that uses the data structure).

If all you're doing is storing a bunch of related data and passing it
around, a simple immutable class may be what you want, assuming it's a lot
of data.

[quoted text, click to view]

IMHO, for that application, it seems to me that using a BinaryWriter is
better, rather than depending on the layout of a struct. It may actually
perform better too, since you theoretically would copy each part of the
data one fewer time (though I admit that if you're doing i/o, that may not
be a consequential difference).

[quoted text, click to view]

There is no magic limit that I know of. That doesn't mean it doesn't
exist; I'm not an expert on the subject.

What I do know is that while there's no magic limit (that I know of),
structs _do_ incur overhead related to the copying of the data within the
struct that classes don't, and as the struct gets larger, this copying
starts to become consequential.

[quoted text, click to view]

The differences between classes and structs are all to do with value
type behaviour vs reference type behaviour. It's not a matter of how
much functionality something's got. DateTime has quite a lot of
functionality, but it's a natural value type. There are plenty of
reference types which are quite simple, but are more naturally
reference types.

Personally I treat class as the "default" and only very occasionally
create structs. In particular, I always avoid creating mutable structs
- they can cause very subtle issues.

--
Jon Skeet - <skeet@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet

[quoted text, click to view]

I find there to be a very simple rule of thumb: if your type warrants
overloading operator== (and other comparison operators) for it, then a
struct is very likely to be a better choice. Otherwise, go for
classes.

This works because overloading operator== typically means you want
structural (value-based) equality, and that is a sign of working with
raw data rather than objects (for the later, you usually care more
about identity).

Performance considerations should be secondary to this, but matter
also. Sometimes you have a raw data object, but with a lot (say, 10+)
of aggregated fields. Semantically, it should be a value type (because
it has strictly value semantics, and identity does not matter), but
copying that much stuff around for every argument/return value becomes
expensive - that's when you go for immutable class (but it is still
best to redefine Equals and overload operator== and != to indicate