Re: Why do we have ipairs?

["Thiago L." <fakedme@...>]

On 10/06/2014 01:31, Coda Highland wrote:
> On Mon, Jun 9, 2014 at 9:14 PM, Andrew Starks <andrew.starks@trms.com> wrote:
> > On Mon, Jun 9, 2014 at 9:25 PM, Thiago L. <fakedme@gmail.com> wrote:
> > > Last I checked, `for x,y in ipairs(t) do` is slower than `for x=1,#t do
> > > local y = t[x]`, so why do we have ipairs()?
> >
> > In 5.2, __len and __ipairs made that a easy answer: you can override them
> > independently. In 5.1, someone else might have a better answer than i.
> # isn't a constant-time operation -- it's O(log n) in the size of the
> table. Furthermore its behavior is only well-defined for a proper
> sequence, wherein the table contains no nil-valued entries with
> integer keys less than the greatest integer key with a non-nil value.
> ipairs(), meanwhile, stops at the first nil value encountered in the
> table. Semantically, ipairs() is the more well-defined behavior.
>
> Ultimately, it's the semantic behavior that gives ipairs() its value
> -- not because it's faster, but because its use parallels the behavior
> of pairs() and any other iterator function defined.
>
> /s/ Adam
I thought # just used the array size? (you know, with OP_NEWTABLE you 
have hash size and array size... I thought # just returned that array 
size...)

Also wouldn't this be faster and behave the same as ipairs: (in 5.1 at 
least... 5.2 can screw itself for all I care about... also I didn't test 
or benchmark it...)
local a,b,c = 1,#t,1
local v = t[a]
while a <= b and v ~= nil do
    -- your stuff here
    -- use this as if it is "for a,v in ipairs(t) do <...> end"
    a = a + c
    v = t[a]
end