wave:

>This is fascinating, Tedd--could you tell us more?  e.g. Suppose the value
>of a variable changed without you predicting it.  How would your program
>know?  And what would it do?  Any why couldn't you do this with regular
>structured programming?

Okay. You asked for it.

>Suppose the value of a variable changed without you predicting it?

That's one of the reasons for setting the entire linked list thing up. In
other words, the variable values can change, but the methodology to
evaluate the data remains the same.

>How would your program know?

It doesn't need to know anything other than when to start evaluating the
data. That's the importance of having functions all lined up as you want to
evaluate data.

I know that this is sounding a little like circular reasoning, but a
example may help.

Let's say that I had numerous data sets that I could load into memory from
a disk file. However, the total amount of data is too voluminous to load
everything in at once. Therefore, I divide the data sets into separate
files and allow the user to pick the file he/she wants.

However, when the user picks the file, I then want the data to be acted
upon by the same functions regardless of what data file is loaded.

>Any why couldn't you do this with regular structured programming?

Well... you could do this with regular structured programming. In fact, I
think this _is_ regular structured programming. It is only differing from
your perceived "structured programming" by the implementation of a linked
list to cascade functions and data via pointers.

Why use a linked list instead of "straight line" program flow? Speed!
Imagine if you had a program that would draw a series of objects. However,
each of those objects had to be calculated before they were drawn. Would it
not be faster to do all the calculations once; store the results; and then
draw the objects from the calculations? My mapping program did that.

My program loaded in a large amount of raw data. The data (literally tens
of thousands of records) was composed of 255 different types of records.
Each record was proceeded by a record ID. Upon reading the ID of the
record, I knew specifically what information would followed, such as a x,y,
or a series of x,y's, or a classification (railroad, stream), or a string,
or a Highway marker, or a ... you get the idea (255 different types).
However, I did not know in advance what the specific values were.

I first analyzed the raw data and broke it down into respective records.
Each record had a function, or functions, that must be called to display
the data. The record had a place in memory for not only the record ID, but
for the data that was associated with the record. In the case of x,y the
data ranged from bytes, short integers, mid intergers, and long intergers.
In the case of strings, the strings had to be logically decompressed and
used as the record dictated (i.e., place Holme's Road at this x,y). In the
case of classifications, these would determine where the following records
would fall into what groups (i.e., waterways, railroads, airports, etc.).
As I said, there were 255 different types of data.

Now, with the data translated into: 1) What to do (what functions); 2)
Where to do it (what data). It became a complex problem that could be
easily solved by using a linked list, such as:

0) Create a linked list and fill it with pointers to functions and data.
1) Start the linked list:
2) Look up the address of a function (function&) from the list.
3) Look up the address of data that the function is going to use (gOffSet&).
4) CALL function& (which uses gOffSet& to find the data to operated upon).
5) Get the next record and repeat the process (2-5) until done.

In this manner, the operation is started by the simple reference to the
first link. Note that no data was moved (a time consuming process). The
data remained in memory and it was not shuffled around into variables
(i.e., x=,y=). Instead, the functions simply referenced the position of the
data via pointers (i.e., gOffSet&) and did their thing. Likewise, the
functions were tied to a linked list and not all the functions in the
program were included within each list. Each function was called as needed
(some many times over) and the entire process was calculated only once, but
called upon numerous times.

So, in some cases it is best to use a linked list.

tedd

___________________________________________________________________
<mailto:tedd@...>	               http://sperling.com/