From one "old" C programmer to another, welcome to the C# fold.
The first question to clear out of the way is whether you are using
..NET (C#) 1.1 or 2.0. This will change the answers you get from some
people in this newsgroup, as some things can be done better / more
clearly in 2.0, while some solutions that work in 2.0 would have to be
reworked for 1.1.
I gave a quick read over your problem description. Forgive me if my
solution is off the mark in a few places: I have a bug I picked up on
vacation and my brain is a bit foggy today.
I'm hoping to give you a little object-oriented background here, and
suggest several solutions that involve varying levels of reworking your
application. Obviously, you don't want to do a whole ton of rework just
to shoehorn the thing into C#, but only you know how much is "too much"
rework, so I'll give you more background than precise code.
Even back when I worked in C, I tended to avoid arrays. I had two small
C source files that I hauled around with me from project to project: an
implementation of a doubly linked list, and an implementation of a hash
table. Over 20 years of programming, I found that 98% of "store stuff
in memory" problems boiled down to storing them in an expandable /
modifiable list, or storing them by key and retrieving them by key.
The problem with arrays is that they're fixed when they're created.
Now, "when they're created" is different in C and C#: in C you
(usually) declare an array and specify its size, and the array is
effectively "created" when the program loads.
In C#, you declare an array without specifying its limits:
double[,] weightAndBalance;
At this point, the variable weightAndBalance contains null: the same,
good ol' null that C had, a null pointer. At that same point, or later
in the program, you have to actually create an _instance_ of that
array, and at that point you say how big you want it:
weightAndBalance = new double[2,34];
You can combine these into one line if you already know, at the point
where you declare weightAndBalance, how big you want it to be:
double[,] weightAndBalance = new double[2,34];
From hereon in, the dimensions of the object to which weighAndBalance
refers ("points to" in C lingo) are fixed. However, you can always toss
that array and have weightAndBalance point to a new one:
weightAndBalance = new double[2,150];
at which point the previous array is fodder for the Garbage Collector
(GC).
Notice that in C an array is (generally speaking) created on the stack
or as part of a static program load, and you use the pointer only when
you need a pointer. In c#, you _always_ have a pointer, and the array
is created dynamically on the heap when you ask that it be created.
Notice also that you don't need to wrap the array in a class: you can
declare it as an array and just pass it around as an array, declaring
method (function) parameters as "double [,]". This isn't very nice,
because if you ever have to change the type, you have to fix it
everywhere. However, a two-dimensional array of doubles is a perfectly
respectable object and you can pass (references to) it around just as
you can for any other object.
Now in your case, it may be that there are always exactly 34 pairs of
numbers in the file. If that is true, you could use an array, but let's
look at two drawbacks of an array in this case, and I can show you two
ways of addressing those deficiencies in C#.
First, there's the case in which each of those 34 pairs of numbers
means something specific. So, it's not that you have 34 interchangeable
pairs of numbers, but that the first pair indicates the frobnitz
coordinates X and Y, the second pair indicates the foobar coordinates X
and Y, etc. This is the case in which the consciencious C programmer
would have made a struct of 34 pairs of doubles, and given each of the
34 (or 68) fields a name. You can do the same in C# with fields and
properties. In this case, your "array" becomes a class with 34 fields
and 34 corresponding properties, where each field returns a
System.Drawing.Point, or whatever corresponds to the meaning of those
value pairs.
Second, there's the case in which those 34 pairs of numbers really are
just captured data values, and the fact that an entry is the fifth
entry, for example, doesn't mean anything special. However, the number
of entires may change in the future. In the old days, I would have used
my custom "doubly-linked-list" .c functions, but C# comes with
ArrayList. You can index it like an array, but the advantage is that
you can add entries one by one:
ArrayList weightAndBalance = new ArrayList();
while reading file...
{
... read firstValue and secondValue from file line ...
System.Drawing.Point aPoint = new Point(firstValue, secondValue);
weightAndBalance.Add(aPoint);
}
Now you can query the number of entries using WeightAndBalance.Count,
and get at any entry using the usual [] notation.
As someone pointed out, though, any part of your program can update
this ArrayList (or array, if the size is fixed and you don't need an
ArrayList) if you return it from a property:
public ArrayList WeightAndBalanceData
{
get { return this._weightAndBalance; }
}
Remember, everything in C# is pointers, so by offering only a "get"
you're denying the caller the ability to change the pointer, but they
still have the power to change the contents of the array to which the
resulting pointer points.
If you have an existing app, you may not care about this: the
application itself may handle who can update what at a higher level.
However, object oriented programming does give you the power to control
this kind of access at the code level, so that the object itself
enforces rules about who can update the data. It all depends upon how
radically you want to reengineer the app you're working on.
Anyway, that's enough babbling for one post. Hope this helped.
).