My point is that the structure is access only three times. Two writes and
one read. This isn't complicated and I don't have to worry about
accidentally assigning a value to the structure while it is being read
somewhere else. That can't happen since the flow is procedural.
I believe that is the red flag some of you were thinking about.
The "red flag" has nothing to do with concurrency. It has instead to do
with semantics. What's missing in this conversation is that nowhere
have you indicated why you _need_ a struct, rather than a class.
structs in C# are very useful, but they are useful for specific reasons
in specific situations. Nothing you've outlined so far indicates that
you're in one of those situations. You may be, but we just haven't
heard why you need a struct here.
So when do you _need_ a struct?
First and foremost, you need a struct when you need something that will
act like a native (value) type: whenever you assign it, it gets copied.
When you pass it as a method argument, it gets copied. In general you
don't care about the _identity_ of the thing: this-one-versus-that-one;
all you really care about its its _value_ (thus the name). Some
examples of structs I've created: a Fraction class, a Measure class
that holds a quantity and a unit of measure. In both of these cases,
Fractions and Measures act like values, like ints or doubles. I don't
_want_ to have a specific instance of 3 3/4 somewhere, with everyone
pointing to it and modifying it. When I assign a Fraction to a variable
I want to create a new Fraction with the same value.
Second, and less common, you may choose to use a struct to improve the
efficiency of your application. This is the one that gets everyone into
trouble with structs.
A word about efficiency: CPU-intensive applications aside (and there
aren't many of those... really, there aren't), you get far, far more
bang for your buck looking for efficiencies in your program's _design_
than you ever will tweaking code. Yes, there are some areas of
programming where both design and tweaking code are required, but as I
said, not many. It's hard to convince newbies of this. So many new
programmers just _love_ poring over their code, tweaking an instruction
here, eliminating a variable there, obvlivious to the fact that there
are huge gains to be had by modifying design or data structures, and
that all of that hand-work they're doing was probably done by the
compiler or the JITter, anyway.
In C#, this manifests itself as a mad dash to turn things into structs
that really have no business being structs, so that the program will be
"more efficient." It also manifests itself as odd questions in
newsgroups, questions like, "Why would anyone want to use a class if
they're less efficient?" A little knowledge, as the saying goes, is a
dangerous thing.
Of course, in using a struct where a class is really needed, one has to
make the struct mutable (give it set accessors), and then the trouble
really starts.
The "red flag" that Ted Miller mentioned is this: structs are useful,
but you don't often run across situations in which you need them. If
you don't need a struct, you're probably better off using a class,
particularly if you don't have a solid understanding of value semantics
versus reference semantics. The problems you're having are likely an
indication that you really want a class, not a struct.
Furthermore, if you create a mutable struct (a struct with settable
properties), then you had better have a _very_ solid understanding of
value semantics and how they differ from reference semantics.
Otherwise, you're going to find strange things happening in your code,
and the few cycles you may have saved by using a struct (if you save
any at all) will be offset by the hours of head-scratching you'll
endure trying to get your program to work. (The upside is that once
you've gone through that pain, you'll either hate structs or have a
solid understanding of value semantics--or both.)
I would make the same claim about exposing mutable structs as part of
the public contract of a DLL for others' use. You had better be sure
that your callers have a _solid_ understanding of .NET value semantics.
Either that or be ready with arguments as to why you had to make
mutable structs publicly visible. Yes, I know that Microsoft did it.
They had very good reasons why they did it. Nonetheless, it still
confuses the %&$# out of a lot of programmers.
Use classes. Use structs only when classes won't do.
