До сих пор единственное решение, которое я нашел, как только проблема происходит, состоит в том, чтобы очистить кэш Firefox.
А лучшее решение было бы намного лучше.
Проблема может быть решена просто путем указания начального и конечного индексов для unpack ()
и использования table.maxn ()
в качестве конца index:
table1 = {true, nil, true, false, nil, true, nil} a1,b1,c1,d1,e1,f1,g1 = unpack( table1, 1, table.maxn(table1) ) print ("table1:",a1,b1,c1,d1,e1,f1,g1) -->table1: true nil true false nil true nil
Истинная причина несоответствия в том, как обрабатываются две таблицы, заключается в логике определения длины части массива таблицы.
Функция luaB_unpack ()
использует luaL_getn ()
, который определяется в терминах lua_objlen ()
, который вызывает luaH_getn ()
для таблиц. luaH_getn ()
просматривает последнюю позицию в массиве, и если она равна nil
, выполняет двоичный поиск границы в таблице («таким образом, что t [i] не -nil и t [i + 1] равно nil ").
When an array has holes--nil elements inside it--the length operator may assume any of these nil elements as the end marker. Therefore, you should avoid using the length operator on arrays that may contain holes.
The unpack()
is using the length operator lua_objlen()
, which "may assume any of [the] nil elements as the end" of the array.
[...] Таблица типа реализует ассоциативную массивы, то есть массивы, которые могут быть индексируется не только числами, но с любым значением (кроме nil). Столы может быть неоднородным; то есть они могут содержать значения всех типов (кроме нуля) . [...]
Если nil
для записи нарушит перечисление таблиц, и ваши переменные не будут инициализированы должным образом.
Вот простой пример, демонстрирующий проблемное поведение :
table1 = {true, false, nil, false, nil, true, nil}
for k,v in ipairs(table1) do
print(k, v)
end
вывод:
1 true
2 false
>Exit code: 0