Problems and techniques to be avoided in Lua iterator use _lua

About the contents of the iterator, there is a little, but it does not matter, should be regarded as an extension of it, together to open the eyes of the good ~

1. Avoid creating closed functions

We have been talking about the iterator, are to create a closed function, but, have you ever thought that with the constant state and control variables, it is not necessary to close the function?
Let's review the previous iterator functions:

Copy Code code as follows:

function Diedaiqi (t)
Local i = 0;
return function (S, VAR)
i = i + 1;

If i > #t then
return nil;
End
return I, t[i];
End, 10, 0
End

This is the last Diedaiqi function that has a constant state and a control variable at this time.
Don't you think that local I variable is a hindrance? (Jor: Don't think)
Just get rid of it, there's no closure function.

Let's change the Diedaiqi function to look like this:

Copy Code code as follows:

function Diedaiqi (t)
return function (S, VAR)
var = var + 1;
If var > #s Then
return nil;
End
return Var, s[var];
End, T, 0
End

We change the constant state to T, and the initial value of the control variable is still 0.
After calling the Diedaiqi function, a new function is returned, which is no longer part of the closed function.
So, according to the introduction of the previous content (not remember to look back), each call function, the parameter s is the table we need, parameter Var starting from 0, instead of the local I variable.

What do you think? Do you feel a little bit more constant and control variables?

2. Create more variables using a constant state

The method just said is good, but can change only one variable, if this iterator needs a lot of variables?

In addition to using closed functions, there is another way-to change eternity into a fickle one.

We continue to modify the Diedaiqi function:

Copy Code code as follows:

function Diedaiqi (t)
return function (S, VAR)
var = var + 1;
If var > #s. List Then
return nil;
End
S.money = S.money * S.money;
Print ("Oh, money, for me, is a number only:" ... S.money);
return Var, s.list[var];
End, {list = T, Money = 10}, 0
End

Notice that the constant state returned now is a table ({list = T, Money = 10}).
This table is still constant during the iteration, but the contents of it are not necessarily the same.
Try calling this iterator:

Copy Code code as follows:

Local T = {"FDSD", "445", "9999"};

For K, v. in Diedaiqi (t) do
Print ("k=" ... K... ", v=". V);
End

The output results are as follows:

Copy Code code as follows:

[Lua-print] Oh, money, for me, is a number just: 100
[Lua-print] k=1, V=FDSD
[Lua-print] Oh, money, for me, is a number just: 10000
[Lua-print] k=2, v=445
[Lua-print] Oh, money, for me, is a number just: 100000000
[Lua-print] k=3, v=9999

What do you think? Although each iteration is the same table, the contents of the table change at any time.
Like some people, the mouth said forever, the action is always changing. (Jor: Are you talking about yourself?) ）

3. iterators that do not require a for loop

Now invoking the iterator is all about using a for loop, actually, a long, long time ago ... Have a ... (Jor: Stop!) I'm not here to hear a story.

Well, actually, in the past, iterators don't use a for statement.

Let's simulate the previous practice:

Copy Code code as follows:

function Diedaiqihistory (T, func)
For i = 1, #t, 1 do
Func (i, t[i]);
End
End

(Jor: I poof, why didn't you do that at first?) How easy is that? ）
Cough, let's try calling this iterator:

Copy Code code as follows:

Local T = {"FDSD", "445", "9999"};
Diedaiqihistory (t, function (k, v)
Print ("k=" ... K... ", v=". V);
End);

So, when we call an iterator, we don't need to use a for loop (although it's still used in the iterator).
And you need to pass a function as a parameter for the callback to get the value of the iteration.

Since I do not have a large number of users in both forms of iterators, so there is no way to compare them.
The author of the book is inclined to use the "modern" iterator.

And I also found that some of the LUA library functions use this form of iteration, perhaps for historical reasons, and perhaps this form has its own particular use.

4. End

Well, about the iterator, it's over.

It's a good feeling, and this is the third time I've been through this book, right? Sure enough to write articles, to understand more thoroughly, the impression is also more profound.

The harder it is to stay back, the more difficult it is.
(Jor: So say!) Why did you use the ellipsis at last? With an exclamation point to appear more energetic ah ... ）