Warum Lua-Länge (#) Betreiber unerwarteten Werte?

Lua hat den # - operator zur Berechnung der "Länge" einer Tabelle als ein array.
Ich habe diesen Betreiber, und ich bin überrascht.

Dies ist der code, dass ich das laufen lassen unter Lua 5.2.3:

t = {};
t[0] = 1;
t[1] = 2;
print(#t); -- 1 aha lua counts from one
t[2] = 3;
print(#t); -- 2 tree values, but only two are count
t[4] = 3;
print(#t); -- 4  but 3 is mssing?
t[400] = 400;
t[401] = 401;
print(#t); -- still 4, now I am confused?


t2 = {10, 20, nil, 40}
print(#t2); -- 4 but documentations says this is not a sequence?

Kann mir jemand die Regeln erklären?

  • Erläuterung der Regeln ist die Aufgabe der Designer. Sie haben dies in den Dokumentation. (Nicht alle Dokumentation ist nützlich für das lernen, aber das ist, wo das lernen sollte beginnen und fortfahren.)
InformationsquelleAutor LeMoussel | 2014-05-11
  1. 27

    Unter Angabe der Lua 5.2 Reference manual:

    die Länge einer t-Tabelle ist nur definiert, wenn die Tabelle ist eine Sequenz, das heißt, die Menge der positiven numerischen Tasten ist gleich {1..n} für einige ganze Zahl n

    Ergebnis # Bediener auf non-Sequenzen ist undefined.
    Aber was passiert in der C-Implementierung von Lua als wir rufen Sie # auf eine nicht-Sequenz?

    Hintergrund: die Tabellen in Lua sind intern unterteilt in Teil-array-und hash-Teil. Das ist eine Optimierung. Lua versucht, zu vermeiden, reservieren von Speicher Häufig, so dass es vor reserviert für die nächste Potenz von zwei. Das ist eine weitere Optimierung.

    1. Wenn das Letzte Element im array zu Teil wird nil, das Ergebnis # ist die Länge des kürzesten gültige Sequenz gefunden binsearching den array-Teil für die erste null-gefolgt-Taste.
    2. Wenn das Letzte Element im array ist nicht nil UND den hash-Teil leer ist, ist das Ergebnis von # ist die physische Länge des Arrays Teil.
    3. Wenn das Letzte Element im array ist nicht nil UND den hash-Teil ist NICHT leer, das Ergebnis # ist die Länge des kürzesten gültige Sequenz gefunden binsearching den hash-Teil für die erste null-gefolgt Schlüssel (das ist eine solche positive ganze Zahl i dass t[i] ~= nil und t[i+1] == nil), vorausgesetzt, dass die array-Teil ist voll von nicht-nils(!).

    So das Ergebnis # ist fast immer die (gewünschte) Länge des kürzesten gültige Sequenz, es sei denn, das Letzte element im array Teil, repräsentiert ein nicht-Sequenz ist nicht-null. Dann, das Ergebnis ist größer als gewünscht.

    Warum ist das so? Wie es scheint, noch eine weitere Optimierung (für Kraft-der-zwei große arrays). Die Komplexität der # auf solchen Tischen ist O(1), während die anderen Varianten O(log(n)).

    • +1 für Erklärungen und links zu spec und Quelle
    InformationsquelleAutor cubuspl42
Schreibe einen Kommentar