lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Am 14.09.2016 um 16:23 schröbte Peter Aronoff:
Dirk Laurie <> wrote:
This turn is caused is caused by the different ways in which the tables
are stored (all in the "array" part in the first case, only one element
in the "array" part in the second case). The details are quite involved
but basically #t will not change as long as you assign to indices that
exist (even if they have value nil)

$ lua
Lua 5.3.3  Copyright (C) 1994-2016, PUC-Rio
t={1,nil,nil,nil,nil,nil,nil,nil,nil,10}   -- indices 1 to 10 exist in the "array part"
#t   -- there is a non-nil at the highest "array part" index
t[5]=5  -- assigning to an existing index does not change #t
t[12]=12  -- non-existing index triggers resizing of "array part"
#t     -- [5], [10] and [12] are now in "hash part"

While we are on this *advanced* subject, I have a question: none of this
“array part” and “hash part” stuff is guaranteed, right? That is, you
shouldn’t rely on it in your code, should you?

No, you shouldn't, because one's assumptions about hash/array parts are often wrong. E.g., on my machine Lua stores `{[1]="a",[2]=nil,[3]="c"}` in hash slots only. I wish people would stop talking about hash and array parts. They are of no consequence except for performance and memory consumption.