On 01/08/14 12:04 AM, Andrew Starks
wrote:
On Thursday, July 31, 2014, Tim Hill <drtimhill@gmail.com>
wrote:
On Jul 31, 2014, at 12:42 PM, Andrew Starks <andrew.starks@trms.com>
wrote:
>
> All of the information efficiently presented and present...
>
> Original:
> `Copies elements from table a1 to table a2. This function
performs the equivalent to the following multiple assignment:
a2[t],··· = a1[f],···,a1[e]. The default for a2 is a1. The
destination range can overlap with the source range. Index f
must be positive.`
More inscrutable to me is why f must be positive.
> I also agree that "table.copy" seems to suggest "any key
value". Obviously its definition clears that up. "table.icopy"
seems to fit "pairs" and "ipairs", but I don't mean to nitpick.
+1 for table.icopy(). However, I would guess that in actuality
this is just a fast, numeric index copy not restricted to
arrays/sequences (which table.icopy() name might suggest). That
is, it works even with holes (nil values) in the copied range,
which is implied by stating that it is equivalent to a multiple
assignment statement.
I see. This also explains the choice in how it was
illustrated. If defaults were (1. #a1, 1), then it could support
both arrays and numeric keys. Then I opt works and it retains
its vararg compatibilities. Correct?
I that I'm going beyond "all comments are welcome" when I
suggest adding features to it, of course.
> It was mentioned that "table.clear" (or similar) was
likely. Was it decided that it would not be useful?
My guess here is that there is no real performance gain. There
are a number of tricks table.copy() can do to optimize the copy
that can’t really be coded in Lua (not saying it DOES these,
just that it COULD), while a clear function in Lua is pretty
much as good as a C version.
—Tim
I thought it was said that internally, Lua could lop off a
single reference, clearing the table in "one" go. That may
have been speculation.
It can set the size to 0, but what about the garbage?
-Andrew
|
