Lemme see if I understand Arrays

[hdm]

If I have, for example, PositionUnit Array, and create multiple positions with this PositionUnit, but set the [numberhere] to anything different for each other it will work ? For example. In one trigger I have Set PositionUnit [1] = there, and other trigger i have Set PoistionUnit [2] = here (the same variable but with other number). Will it work ? No crash ? No bug ? (except for the leak that I can remove) Or do I have to create other variable ? Like in one trigger Set PositionUnit and in the other Set OtherPositionUnit ?

 

[edo494]

that is exactly what array is actually. Array basically represents collection of variables that have the same name and are only differentiated by integer value. This has several applications, like easy iterating compared to having 10 variables with different names.

However, when it comes to Location variable, if you dont use Wait, Polled Wait or timer expire events, you dont really need to array it, but you still can

 

[Chaosy]

It seems like you get the concept.

Basically:

castLocation = Location of Triggering Unit
targetLocation = Target point of ability being cast

>

location[1] = Location of Triggering Unit
location[2] = Target point of ability being cast

[x] each number is a unique variable.

 

[chobibo]

Think of arrays as your fingers, each finger can hold rings (data). They're all fingers but the rings are placed on a specific finger.

let f be the group of fingers (on your hand) and the numbers be the individual finger;

f[1]=no ring,f[2]=no ring,f[3]=no ring,f[4]=no ring,f[5]=no ring;

now, if you wanted to put the "ruby ring" on the fifth finger on your hand, you do this;

set f[5]=ruby ring

That's about it. Simple ain't it?

 

[WaterKnight]

Arrays are a type of data structure. Data structure means it's a compound of multiple elements organized in a certain way. Arrays are a very simple case where the elements have to be of the same type and you store/read the individual element by presenting an integer index, for one-dimensional arrays at least. Imagine the table in Excel, just use one column, then you have a number of rows each with a certain position (a vector), those are the slots, the position is the index. A two-dimensional array would be multiple columns and rows (a matrix), so you provide two indizes. A three-dimensional one would be like multiple Excel tables and so on. However, Wc3 natively only supports 1d arrays. The index range is from 0 to 8190 statically (8191 is kinda bugged).

The major advantage of data structures is that you can write the code more dynamically. For example, if you wanted to count the kills of multiple units separately, it would require multiple integer variables and you would have to pick the right variable for the unit. This would result in IF/THEN/ELSE branching or more triggers, one solution for each unit. The problem arising becomes even more evident when more units spawn during runtime. You won't have code prepared for them, at maximum have reserves, but that would be a big mess and quite limited. So a proper solution would be to give each unit a unique index for an array (at least until it gets removed again) and dynamically address the memory space meant for the specific unit by presenting its index to the array. It's similar as if you were creating new variables during runtime.

 

[Vinz]

It seems like you get the concept.

Basically:

castLocation = Location of Triggering Unit
targetLocation = Target point of ability being cast

>

location[1] = Location of Triggering Unit
location[2] = Target point of ability being cast

[x] each number is a unique variable.

This. I suggest instead of creating ~5 temp point variables, use TempPoints[] instead (with the 's' so it is distinguished between maps).

 

[WaterKnight]

It's better to use dedicated variables though because else you have to pay attention to not call events. You cannot have triggers carelessly running in parallel when using superglobals.

 

[edo494]

you cant have triggers running in parallel anyway, + superglobals? This ain't no PHP!

 

[WaterKnight]

You know what I mean, nesting trigger calls, waits. Superglobals in the sense that they are not bound to a scope, even if this is not technologically forced.

 

[Dr Super Good]

This. I suggest instead of creating ~5 temp point variables, use TempPoints[] instead (with the 's' so it is distinguished between maps).

Actually that is not the recommend approach. In C/C++ you can get away with it because the static index compiles to a constant offset (similar to reading struct/class members) however in JASS it is a fully parsed argument which requires another stage of execution. As such you should use arrays as a dynamic storage space and instead use non-arrays for static storage.

It's better to use dedicated variables though because else you have to pay attention to not call events. You cannot have triggers carelessly running in parallel when using superglobals.

The memory model of WC3 is such that only 1 thread is ever accessing it at any time and that all changes it makes are immediately consistent with the next running thread. Since this implies that 2 threads can never run simultaneously it is impossible for triggers to be "running in parallel".

The problem with global registers (more appropriate name than "superglobals" since they act more like processor registers) is that like all registers they can only be assigned to store one value at a time for a job. If the job generates another jobs that needs to use the same global register then the value of the register has to be stored somewhere. By the time the original job resumes the value in the global register has to be restored again so as to prevent a loss of data. This is your basic function/interrupt call procedure where it dumps registers to stack at a time defined by architecture and call convention.