MasterLee wrote: ↑Fri Mar 24, 2017 2:19 pm
Ok, let's make it short; lua has no native integer support.
The arrays starting with one are a little bit painful sometimes;
For example, when you have an canvas of width 800, i goes from 0 to 799 in löve2d, but arrays go from 1 to 800, by default.
Next, when you wrap around, you could write
in cpp, but in lua, it becomes
when using 1-based arrays.
Löve comes with luaJIT; luaJIT comes with an FFI interface; The FFI interface allows you to define C types on the lua side; now you have integers, arrays, structs, unions, etc...
Nothing is forcing you to use 1-based indexing, just forget about ipairs and #; for loops will work with whatever limits you give it. (And yes, the 1-based modular arithmetic does tend to get on my nerves as well, but again, you can use 0-based indexing if you wish, it won't incur any performance penalties or anything.)
(And yes, i'm assuming that the discussion
was about Löve
(or at the very least, luaJIT), not just plain lua.
)
Also, that nekoVM site's claims about lua are interesting, and in some places either a bit counterintuitive, or (at least to me, seemingly) wrong.
nekovm.org/lua wrote:bool in Lua (true and false) is similar to the Neko bool except that in Neko only one instance of true and one instance of false are allocated and shared by all the code.
Not sure what is being implied here; i'm pretty sure lua doesn't "instance" booleans either. Maybe it's just talking about how neko's runtime representation mentioned below is somehow more optimal with them? (It would still need to refer to them, so i believe a pointer may have a larger (or equal) footprint than just storing a representation of the boolean true or false... i could be wrong though.)
nekovm.org/lua wrote:One large difference is that Neko's strings are mutable, that is, they can be modified at runtime. This makes an operation like reading a file to a string byte by byte a fast, efficient, linear operation. By contrast, if you were to try and do this in Lua (which has immutable strings), the operation would be quadratic and become prohibitively slow for even files of a few kilobytes. Lua offers a facility, table.concat, to alleviate this problem; but it still bites programmers on occasion.
I mean, sure, if you're reading a file in one byte at a time, even C tends to choke on it... reading n bytes at once with io or Löve's own filesystem stuff is fine as it is; also, immutable strings are a problem with concatenation, reading in n bytes from a file at once won't concatenate the input byte-by-byte. No need to use tables either, if you want to preserve memory, and are fine with one string.