[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: C API - lua_next traversal of "array" table
- From: Ross Berteig <Ross@...>
- Date: Thu, 18 Aug 2016 10:20:43 -0700
On 8/17/2016 5:50 PM, Vaughan McAlley wrote:
On 18 August 2016 at 07:14, Ross Berteig <Ross@cheshireeng.com> wrote:
But note that it is possible to construct a table in such a way that it has
only integer keys, and yet nearly all are still stored in the hash table and
not in the efficient array part. A lot of effort has gone towards making
such a pathological case difficult to achieve, but there is nothing in the
spec that forbids that. Such a table would iterate keys in a completely
arbitrary order with lua_next().
Would it be reasonable to assume you will be OK if you don’t construct
the array part of your table “pathologically”?
Nope. The "array part" is an implementation detail. If it happens to be
used, it will be iterated first, but you cannot assume that it either
exists or will be used. It is not part of the specification of a table.
The next version of Lua could choose to iterate the array part in
reverse order or after the hashed keys and, while either would be
surprising, it would not be a bug because nothing requires either that
there be an array part or that it be iterated in a particular direction
or at a particular time. Your only guarantee is that lua_next() will
make a complete pass through all the keys.
Yes, you will probably get away with it. Until you ship the code
somewhere it can't be easily fixed, or your reputation depends on it
behaving, or Murphy's Law catches up to you.
Honestly, the cost of writing a loop over integers from 1 to #t is so
low (even in C) that you should just do that rather than assume that an
undocumented behavior will work under all conditions.
Ross Berteig Ross@CheshireEng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602