Another colleague made a mistake on the length of the LUA table, let's take a look at it ~ ~ ~
Look at the following code:
Copy Code code as follows:
Local TblTest1 =
{
1,
2,
3
}
Print (TABLE.GETN (tblTest1))
The result of this code output is 3, which everyone knows, right. Whether the last 3 followed by a comma, the result is 3.
Then look at the following code:
Copy Code code as follows:
Local TBLTEST2 =
{
1,
A = 2,
3,
}
Print (TABLE.GETN (TBLTEST2))
What is the result of this code output? The output here should be 2. First of all, understand that this tblTest2 is not a simple table, it mixes lists (list) and records (record) two styles, in the table, a = 2 is the recording style. Second, realize that the record-style record is not calculated as the length of the appearance (the key value cannot be evaluated at the index position). You can think of it as a function, like other object-oriented languages, where functions are not recorded as internal variables.
Since, like a function, you can output the value of a, yes. Print (tbltest2.a) is OK.
The key value corresponds to the index, and the key value can correspond to the index such as the following:
Copy Code code as follows:
Local tbltest =
{
[1] = 2,
[2] = 3,
[3] = 10,
}
Print (TABLE.GETN (tbltest))
[1],[2],[3] can correspond to the index position, so output 3, if the key value does not correspond to the index, then the result is often wrong, such as:
Copy Code code as follows:
Local tbltest =
{
[1] = 2,
[2] = 5,
[4] = 10,
}
Print (TABLE.GETN (tbltest))
The output from the above code is 4, but this one below is 2,
Copy Code code as follows:
Local tbltest =
{
[1] = 2,
[2] = 5,
[5] = 10,
}
Print (TABLE.GETN (tbltest))
In addition, there is a mix style, such as
Copy Code code as follows:
Local tbltest =
{
2,
[3] = 2,
4,
}
Print (TABLE.GETN (tbltest))
3 and [3] can be mixed, so the output here is 3
There is also a rule that when you use a list style, each time you first look for [1] location before starting to calculate .... In fact, can be understood as first find 1, and then sort, and then calculate the length ~ ~ ~
It is recommended that you do not mix Recrod and list styles in the table, and then calculate the length unless you are very clear about the rules between them, and in addition, the key in the list style is not counted if it is not a number ~ ~ ~
Then look at the following code:
Copy Code code as follows:
Local TBLTEST3 =
{
1,
{a = 2},
3,
}
Print (TABLE.GETN (TBLTEST3))
What is the result of this code output? The output here should be 3. Note that table nested tables are also elements of nested tables. So, the result of the output is 3.
The following situation is quite tangled, can directly see the last sentence summary:
Now look at a more tangled:
Copy Code code as follows:
Local TBLTEST4 =
{
1,
Nil
}
Print (TABLE.GETN (TBLTEST4))
What is the result of this code output? is 1. We all know that when the table gets the length, it traverses the entire table and returns at the last non nil place.
But what about the following code?
Copy Code code as follows:
Local TBLTEST5 =
{
1,
Nil
2,
}
Print (TABLE.GETN (TBLTEST5))
The above code, the result is as follows:
Fun, huh? It also calculates the length of the nil as an element. But what you can't touch is the following code:
See, the result of this code is 1. Send another paragraph, and let you completely cast off:
Look, this code output is 3, isn't it? Look again, this section is called you hereafter dare not again to write nil value in table:
Look, the output of this section is 1. Pro, excuse me, do you dare to use nil value in the Lua table later??? If you continue to add nil to the back, you may find something. You might think you're finding a pattern. But you mustn't think of it as a rule. Because it's wrong.
1. Do not use nil in table
2. If you want to use nil, you must use the TABLE.SETN () function to set the length of the table. Note: The new version of LUA does not support SETN anymore.
Must give you a conclusion:
The SETN function is obsolete, do not use the nil value in a LUA table, and if an element is to be deleted, remove it directly, and do not replace it with a nil.