Arrays or Structures?

jjames

I'm going to guess that this thread may eventually get thrown into the tips and tricks section, but I'd thought I'd start here.

Before I was introduced to the real power of arrays, I used individual variables for every little thing. It's funny to look at my very first weather.com parsing code block; it was a 400 line code block with over 100 variables. Now I've shortened it down to less than 90 lines of code and 10 local/stack variables, and mainly all because I'm using multi-dimensional arrays.

Now I don't know much about structures since I've never used them since the Programmer practical, but I'd like to hear about them and if you use them, how do you use them? Do you find them more flexible / efficient than arrays that COULD be taking up unused memory?

Or are we comparing oranges to applies here?

Marc Scheibein

Since I have understood how to use structures, I wonder how we did that in the past in AXcess without them..

Structures are very helpful to manage/store datasets, especially if the are of different type

DEFINE_TYPE
STRUCTURE _sBeamerState
{
CHAR SerialNum[30]
INTEGER Lamptime
INTEGER Input
INTEGER Volume
INTEGER Power
}

DEFINE_VARIABLE
_sBeamerState BeamerState_Unit1
_sBeamerState BeamerState_Unit2
_sBeamerState BeamerState_Unit3
_sBeamerState BeamerState_Unit4


DEFINE_PROGRAM
[dvPanel,11] = (BeamerState_Unit1.Power=1)
[dvPanel,21] = (BeamerState_Unit2.Power=1)
[dvPanel,31] = (BeamerState_Unit3.Power=1)
[dvPanel,41] = (BeamerState_Unit4.Power=1)

Or think of phonebook listings where you need full datasets

DEFINE_TYPE 
STRUCTURE _sPhoneBookData
{
CHAR FirstName[20]
CHAR LastName[40]
CHAR CompanyName[50]
CHAR Phnoe[30]
}

DEFINE_VARIABLE
_sPhoneBookData PhoneBook_CEO[100] // 100 datasets 
_sPhoneBookData PhoneBookTemp


DEFINE_PROGRAM
PUSH[dvPanel,1] // select a phonebook dataset for editing
{
PhoneBookTemp = PhoneBook_CEO[3] // copy complete dataset to temp for editing
// now edit the elements of PhoneBookTemp
}

PUSH[dvPanel,2] // save the edited phonebook data back to list
{
PhoneBook_CEO[3] = PhoneBookTemp 
}

But depending on the application and functions I need I'm still using arrays.

INTEGER nMatrixOutputs[16]
// Matrix has 16 outputs, in the nMatrixOutputs elements is stored the current input routed to the out

One disadvantage of structures is that you can't pass them directly in/out of a module....

DHawthorne

I love using structures, but the fact that you can't pass them to a module limits them dramatically in usefulness. I would use them a whole lot more often if not for that. But I don't think this is an either/or kind of situation; there is a place for both. If all your data is of the same type, use an array, or multidimensioned array (I've had them as deep as four, but it gets unwieldy to the point of diminishing returns; I consider 3 the practical limit in most cases). If there are different types intrinsically linked, use a structure.

Structures are by far easier to keep track of. If I have a data listing ... lets say I am controlling thermostats, and am tracking room temperatures, I can make an array for those like so: INTEGER iTemps[NUMBER_ROOMS][3], which holds current temp, heat setpoint, and cool setpoint. But when I refer to iTemps[3][2], the only way I can keep track of what the 2 is in the second index is to make it a CONSTANT reference (which is easy enough to do, but this is just an example, so I'm keeping it simple). In structure format, it would be something like:

STRUCT strTemp
{
    INTEGER Current
    INTEGER HeatSet
    INTEGER CoolSet
}

... and I could then make an array of these for the rooms -

strTemp nTemps[NUMBER_ROOMS] ;

You would then reference each temperature by nTemps[CURRENT_ROOM].Current, etc., and know exactly what you were referencing without having to look anything up.

In a simple situation like above, I wouldn't bother with the structure. I would just make a couple of CONSTANTs to reference my indices and use a multidimensined array. But if your data was more complex - lets say you were tracking not only temperatures, but setback times and the actual room names too, then a structure would make more sense. But you can't pass it as an argument to a module .

Chip Moody

Love structures to death for keeping data organized in situations where you used to have multiple arrays of different types/sizes for a database type of thing... Love 'em.

- Chip