Cassandra Posted February 18, 2013 Posted February 18, 2013 Edit: What is the difference between ipairs and paris?
Sparrow Posted February 18, 2013 Posted February 18, 2013 Remember ipairs work only with number indexes and number indexes should be order. ( 1,2,3,.. ) not (1,3,5,.. ) pairs work with all indexes.
Gallardo9944 Posted February 18, 2013 Posted February 18, 2013 for i,v in ipairs(table) do i = iteration number v = value of the table, it equals table for v in pairs(table) do v = value of the table. You can't get the iteration number here.
Moderators IIYAMA Posted February 18, 2013 Moderators Posted February 18, 2013 Will it give lagg when I use ipairs instead of pairs at moments, I don't need to know the location of the source? short:(lagg?) I have a table but I don't need the iteration number, while using ipairs.
Moderators IIYAMA Posted February 18, 2013 Moderators Posted February 18, 2013 but pairs is better when you don't need that number?
Gallardo9944 Posted February 18, 2013 Posted February 18, 2013 basically no, you won't find any difference.
Moderators IIYAMA Posted February 18, 2013 Moderators Posted February 18, 2013 basically no, you won't find any difference. Maybe one more byte looping through the script
csiguusz Posted February 18, 2013 Posted February 18, 2013 for v in pairs(table) do v = value of the table. You can't get the iteration number here. That's not true. ipairs is for indexed tables, it means every item (value) in the table has it's own number: 1 is the index of the first value 2 is the index ot the second's and so on. Example: local indexedTable = { 2, "something", 8239713, "asd" } -- it's is equal to this: local indexedTable2 = { [1] = 2, [2] = "something", [3] = 8239713, [4] = "asd" } --both pairs and ipairs will work in those tables: for i, v in ipairs( indexedTable ) do -- i is the index and v is it's value -- this does the same as above: for i, v in pairs( indexedTable ) do pairs is for not-indexed tables, where instead of the index number can be anthing (numbers or strings) and they can be the same too. --both pairs and ipairs will work in those tables: for i, v in ipairs( indexedTable ) do -- i is the index and v is it's value -- this does the same as above: for i, v in pairs( indexedTable ) do local table = { ["string"] = 2, [7] = "something", ["lua"] = 8239713, [2231] = "asd", ["lua"] = "i have no idea what to write here...", } -- ipairs won't work in this case. for k, v in pairs( indexedTable ) do -- for pairs instead of "i" I usually use "k" wich means key (of the value). -- so, k will be the key( e.g. "string" at the first in this example ) -- and v will be it's value
Cassandra Posted February 18, 2013 Author Posted February 18, 2013 for v in pairs(table) do v = value of the table. You can't get the iteration number here. That's not true. ipairs is for indexed tables, it means every item (value) in the table has it's own number: 1 is the index of the first value 2 is the index ot the second's and so on. Example: local indexedTable = { 2, "something", 8239713, "asd" } -- it's is equal to this: local indexedTable2 = { [1] = 2, [2] = "something", [3] = 8239713, [4] = "asd" } --both pairs and ipairs will work in those tables: for i, v in ipairs( indexedTable ) do -- i is the index and v is it's value -- this does the same as above: for i, v in pairs( indexedTable ) do pairs is for not-indexed tables, where instead of the index number can be anthing (numbers or strings) and they can be the same too. --both pairs and ipairs will work in those tables: for i, v in ipairs( indexedTable ) do -- i is the index and v is it's value -- this does the same as above: for i, v in pairs( indexedTable ) do local table = { ["string"] = 2, [7] = "something", ["lua"] = 8239713, [2231] = "asd", ["lua"] = "i have no idea what to write here...", } -- ipairs won't work in this case. for k, v in pairs( indexedTable ) do -- for pairs instead of "i" I usually use "k" wich means key (of the value). -- so, k will be the key( e.g. "string" at the first in this example ) -- and v will be it's value Thanks a lot. Now I finally know the difference between them.
Anderl Posted February 18, 2013 Posted February 18, 2013 Just in case someone thinks that an array with only numbers as indexes is an indexed array too, no, it isn't. An array needs all indexes in the right order to be an indexed array. for i,v in ipairs(table) do i = iteration number Not really, "i" can be anything else, and it has the value of the index (example: table["example"] = "example_1"; --here, "example" is the index, and it IS NOT a number). v = value of the table, it equals table Not the best explanation, but you can say that.
Anderl Posted February 18, 2013 Posted February 18, 2013 You've got to control threads by yourself when loading LUA code in a software AFAIK (in this case, it's the MTASA). Not sure if this is what you're talking about.
Cassandra Posted February 18, 2013 Author Posted February 18, 2013 You've got to control threads by yourself when loading LUA code in a software AFAIK (in this case, it's the MTASA). Not sure if this is what you're talking about. For example if I have a code like this. function doSomething() for 1, 1000000 do print("Did!") end end function doAnother() print("Did!") end doSomething() doAnother() Will it prints the doAnother first or wait for doSomething to complete then move onto doAnother?
Anderl Posted February 18, 2013 Posted February 18, 2013 It will wait for 'doSomething' to finish and then call the next. You can use coroutines to "bypass" that, though (it's like a threading library, built into LUA).
Gallardo9944 Posted February 19, 2013 Posted February 19, 2013 function doSomething() for i=0, 1000000 do print("Did!") end end function doAnother() print("Did!") end doSomething() doAnother()
Anderl Posted February 19, 2013 Posted February 19, 2013 function doSomething() for i=0, 1000000 do print("Did!") end end function doAnother() print("Did!") end doSomething() doAnother() for index = 1, 1000000 do print ( "Did!" ); end Arrays in LUA start in index 1, not 0
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now