Array dimensions: good practice and redimension

Monkey Forums/Monkey Beginners/Array dimensions: good practice and redimension

abakobo(Posted 2015) [#1]
Hi

Arrays have to be dimensionned for android but not for html5

this will work on android and html5


this will crash on android but work on html5



What's the good practice? How can i redimension my array if i have to give it a dimension at declaration?

thx


Nobuyuki(Posted 2015) [#2]
best practice for redimming an uninitialized array:



arrays are not dynamic by default in Monkey. For that you'd want to use a Stack<T>. This code shows you how to adjust the size of the array at runtime, but I believe depending on the platform, this may realloc the array. The reason why your example 'works' on html5 (I believe) is because javascript uses dynamic arrays. In fact, I don't know why the second example doesn't crash at runtime for you, since trying to access a member of an uninitialized array should throw a Monkey error ("Index out of range").


muddy_shoes(Posted 2015) [#3]
Monkey will only catch array bounds errors in debug builds. In release mode you don't want those checks slowing your code down.


ImmutableOctet(SKNG)(Posted 2015) [#4]
@Nobuyuki: That's not really the best practice at all. You should be checking against the 'Length' property. All arrays are stack-allocated on the standard C++ targets, but they point to the heap. And since they use a very lightweight wrapper on those targets, they don't really have error handling in release mode. In other words, they're directly accessing memory. And a call to the 'Resize' routine is generally problematic, as it usually just generates a new array.

The fact is, an uninitialized array's data is "undefined". The best course of action would be to check against the 'Length' property, and resize accordingly. That being said, an array that's uninitialized should either be detected and dealt with, or used regardless. This can be done by allowing Monkey to cause a runtime error (Doing nothing; not really recommended), or you check against the length. Ideally, if you don't expect bad input to a function or method, it's best to specify that it's up to the user.

Personally, I'm not even for using 'Resize' for anything but resizing with the expectation of a new array container (If not a full allocation). This is target-dependent at the end of the day, so it's best to write portable code wherever possible. You could technically write a function to produce the same array if it's the intended size, but that's still inefficient on some targets. Sure, it's not that bad, and it can be optimized out, but it's better to just make a small check. I think there's also a default check if you just use it as a boolean.

Example:


That's about it. I personally go for the manual 'Length' check, myself. It's not like there's any difference besides relying on the compiler.


Gerry Quinn(Posted 2015) [#5]
Umm... what's wrong with just initialising ALL arrays at the point of declaration (or just after if you just want an alias for an existing array?)