 |
lua-l archive |
|
|
||
|
On 8/17/2016 1:45 PM, ThePhD wrote:
I knew that to be the case, but I was hoping that perhaps there was some amount of a guantee... ah, well. The good news is: Lua 5.0, 5.1, 5.2, 5.3 and LuaJIT all iterate through arrays in the order 1, 2, 3, ..., N, for both large and small array size N, so I can just quietly let it work and then freak out later when some newer version of Lua changes the behavior. It's not the best... but it'll do for now.
No, it doesn't.True, if some keys are in the optimized array part, they will be iterated first by lua_next(). But it is both possible and reasonably likely for larger integer keys to still be in the hash part. So the result could be 1, 2, 3, 4, 5, 6, 7, 8, 13, 9, 10, 12, 11.
The "array part" is just an optimization, to speed up the likely case of access to small integer keys. Nothing guarantees that it is even used for any particular table. But it is likely that some span of the range will end up in there.
If you just assume it works, you will have mysterious bugs that will be very hard to reproduce since the choice when to move keys from hash to array is made at run time and is highly dependent on the sequence of operations on each table.
-- Ross Berteig Ross@CheshireEng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602