Re: Struct vs Class

Holy poop, DictionaryEntry is mutable? (off to MSDN).... Whoa. Oh,
and my comment about avoiding including value-types in structs was from
the optimization direction - obviously if you're using structs because
you want value-type semantics then it doesn't matter what you stuff in
them (as long as they're immutable to avoid confusing aliasing
behaviour).

Funny that nullables are value-type - I recently got an error from the
XmlSerializer where it complained that they were reference types, and
thus couldn't be XmlAttributes. That was just silly.

Anyhow, I think the reason DictionaryEntry is mutable is just because
people got really sick of saying new DictionaryEntry<MyKeyType,
MyValueType> - not for any good technical reason. I think it's
hilarious that the structs have the nice immediate-setting semantics
for mutable structs
myStructClass foo;
foo.bar = 1;
foo.baz = 2;
//all parameters initialized, it's ready to use, no constructor
needed.

but you can only use them with mutable structs anyways, making it
completely useless since MS says to never-ever-do-mutable-structs. I
want the readonly attribute to apply to property setters, and then
integrate that with the 3.0 Object Initializers so we can have some
non-excruciating syntax for immutables.

Dave Sexton wrote:
Hi Bruce,

Of course, structs that contain references to _mutable_
objects can lead to some awfully puzzling, nearly-unpredictable
behaviour, so I wouldn't recommend that. :-)

DictionaryEntry is one that doesn't conform to that idea, however.

--
Dave Sexton

"Bruce Wood" <brucewood@xxxxxxxxxx> wrote in message
news:1162229711.383330.47510@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Martin Z wrote:
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.

Apparently so. I'm trying to think of differences in behaviour between
an immutable class and a struct, and I can't. Of course, it's Monday
morning. I could be wrong.

One would have to overload == appropriately (and, one presumes, the
other mathematical and comparison operators), but apart from that I
can't think of any hitches. Of course, the temptation with a class
would be to make it mutable, but that's just a temptation, not a given.

The struct is primarily a speed-optimization - access to stack-variables is
much faster.

I wouldn't state that as the primary speed benefits of structs. I
consider the primary speed benefit of structs being that they don't
need to be garbage-collected. So, if you are doing extensive
calculations that involve the creation of myriad intermediate results
then structs are a better choice because objects created on the heap
have to be GC'd.

However, this is only one consideration in whether to make something a
struct or a class, and not even the most important. The most important
consideration, IMHO, is whether the thing you want to create displays
_value semantics_. There are lots of discussions in this newsgroup
about struct vs class and value vs reference semantics.

Hence, structs should only contain other valuetypes.

No, I disagree. For example, I have a struct called a Measure, which
contains a decimal quantity and a unit of measure. UnitOfMeasure is a(n
immutable) reference type. I think that our disagreement on this point
goes back to the speed benefits of structs: I see storage on the stack
as a side-effect of using structs, not as a motivation for using
structs, and so I don't see anything wrong with structs that contain
references. Of course, structs that contain references to _mutable_
objects can lead to some awfully puzzling, nearly-unpredictable
behaviour, so I wouldn't recommend that. :-)


.

Relevant Pages

  • Re: Structs vs. Classes
    ... Classes are created on heap while structs are created on stack. ... different from "Bob Smith, customer #1234". ... reference to that customer in your entire program see that change. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Naming structs with a variable
    ... Structs exist for the purpose of being more lightweight than ... I would agree if you'd just said that structs are lighter weight ... a literal reference from an authoritative source: ... *know* causes confusion on the grounds that people should learn more ...
    (microsoft.public.dotnet.languages.csharp)
  • Beware CS1612 when dealing with "Point" (its not really a structure like most of us think of)
    ... modify a Point, which I had made have a property. ... like 'int' or 'nullable' types, and does not really have 'member ... allow you to return a reference to a value type. ... The only issue I have with the way that structs are implemented ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Reference to a struct inside its definition
    ... But the more general issue here is that you've got a data type that you expect to be stored as a reference on a regular basis, making it more appropriate as a reference type than a value type. ... Generally speaking, classes are reference types, while structs and primitive types are value types. ... If you assign a value type to a variable that's of type object, or pass it as a parameter of type object, etc. the compiler will generate code that creates an object instance that contains the value type you've used. ... If you box the same value instance multiple times, you get multiple instances, each with a new copy of the value type. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: malloc vs new for POD types
    ... You don't update the reference count if you blindly copy ... constructor and assignment operator. ... purpose is to do something important if the object is copied or assigned. ...
    (comp.lang.cpp)