array.length exist in any decent programming language...
Nope a lot of languages lack them. Technically arrays have no length as they memory lookup instructions. The logical length of the array is however big the space one has allocated for it is. As soon as one assigns a size property to an array that becomes an extra piece of data to store which can add considerable overhead for lots of small arrays. Some modern compilers that know the length of arrays at compile time will optimize out such length property with constants.
Generally only safe languages like C# and Java give arrays an automatic length. They also perform bounds checks on access and assignment. All of these add overhead, but such overhead is often worth while as it makes them immune to typical buffer overrun problems.
C++ offers vector and other classes which provide functionality similar to a managed array. Again there will be overhead associated with this both computationally and memory.
create 1 BonusItem[Math:random number between 0 and array.length] at position of dying unit
Since arrays in WC3 can always be considered as empty 32,768 element banks one has to manually track the number of elements one stores in them. Hence when you are filling the array with data you should also be counting how many elements you added to it. Generally the result is closer to a typical collection API than an actual array.
Technically the size of a JASS array depends on the largest index.
I recall people posting in the past that they are dynamically expanded by powers of 2. Hence even knowing the maximum used index will still not reveal the actual underlying size, unless maybe some maths were performed on it. However why one would ever need to know this is beyond me.
With the way I made this system I'm not even sure how I would use a counter to find the size of the array.
Instead of hard coding array indicies when defining the data, dynamically code them. For example...
Set LowGradeConsumableItem[0] = Healing Salve
Set LowGradeConsumableItem[1] = Lesser Clarity Potion
Becomes...
Set LowGradeConsumableItemCount = 0
Set LowGradeConsumableItem[LowGradeConsumableItemCount] = Healing Salve
Set LowGradeConsumableItemCount = LowGradeConsumableItemCount + 1
Set LowGradeConsumableItem[LowGradeConsumableItemCount] = Lesser Clarity Potion
Set LowGradeConsumableItemCount = LowGradeConsumableItemCount + 1
Not only is this more maintainable since one can modify ordering with trivial effort, but it also leaves the count of elements in LowGradeConsumableItemCount which one can use at a later time, eg to get a random element from the list.
especially since this array is defined at the start of the game and does not change ingame.
Except they do change in game. JASS arrays (used by GUI) are dynamically expanding storage spaces that can expand to a maximum size of 32,768.
Arrays are not lists. What you want is a list of elements. A list has an element count. One has to explicitly program list like mechanics in JASS, like shown above.
That way, I could dynamicaly increase and decrease the array size, which seems not very right.
Once JASS arrays are expanded they will never decrease in size. This is the result of there being no API to instruct the virtual machine that an array index is no longer required. As far as the programmer is concerned they are always arrays with a size of 32,768, although the backing allocated memory will be smaller than that unless the larger index numbers are used.
In C-like languages I know we can not really re-allocate memory dynamically, but just maybe re-locate it, meaning deleating the whole thing, and allocating it again in a re-sized form, which then would result in true new array length.
C memory API supports memory resizing. If it ever resizes the allocated memory is another question and one that I am sure is implementation specific.
JASS arrays might attempt a resize, however it is unlikely to succeed in most memory allocation approaches. Hence it is most likely that the memory resize that occurs when JASS arrays dynamically expand starts off by allocating new memory somewhere else, copies the contents of the old memory across and then frees the old memory. This overhead can be considered trivial as it will occur only once and involve at most 32,768 * 4 bytes.
