Page 1 of 1
Table1 = Table2, how does this actually work?
Posted: Sun Nov 24, 2024 11:54 am
by Bugala
Here a test code:
Code: Select all
Table1 = {1, 2, 3}
DebugPrint(table1[1])
Table2 = Table1
DebugPrint(Table2[1])
table2[1] = 7
DebugPrint(table1[1])
DebugPrint(table2[1])
table1 = {4, 5, 6}
DebugPrint(table1[1])
DebugPrint(table2[1])
I always assumed that Table2 would be a reference to Table1, as can be seen from "table2[1]=7" affecting both table1 and table2.
But when I empty Table1, Table2 seems to continue to exist still?
So how do Hollywood tables actually work when using Table1 = Table2, is it that Table1 and Table2 are both referencing to same memory location, instead of table2 referencing to table1, and when doing "Table1 = {4, 5, 6}" it now points to whole new memory location as in making a new table, while the Table2 continues to referencing to the same old memory location?
And if this is the case, then is it safe to continue using Table2, or might that memory location suddenly just disappear?
Re: Table1 = Table2, how does this actually work?
Posted: Sun Nov 24, 2024 1:28 pm
by Flinx
Interesting. I tried to add a
CollectGarbage() and it didn't change anything. So you could assume that as soon as table1 is assigned a new table (or Nil), table2 is independent.
But that doesn't seem to be described in the manual.
Re: Table1 = Table2, how does this actually work?
Posted: Sun Nov 24, 2024 1:43 pm
by emeck
From lua's documentation (
https://www.lua.org/pil/2.5.html):
Code: Select all
A table is always anonymous. There is no fixed relationship between a variable that holds a table and the table itself:
a = {}
a["x"] = 10
b = a -- `b' refers to the same table as `a'
print(b["x"]) --> 10
b["x"] = 20
print(a["x"]) --> 20
a = nil -- now only `b' still refers to the table
b = nil -- now there are no references left to the table
When a program has no references to a table left, Lua memory management will eventually delete the table and reuse its memory.
Re: Table1 = Table2, how does this actually work?
Posted: Mon Nov 25, 2024 2:43 pm
by Bugala
Thanks Emeck. I guess this explains the situation, and I assume Hollywood being based on LUA operates the same way.
Re: Table1 = Table2, how does this actually work?
Posted: Mon Nov 25, 2024 6:01 pm
by emeck
@Bugala
it is also more or less what is explained in the
CopyTable() of Hollywood's help:
Code: Select all
This function can be used to make an independent copy of the specified source table. As you have probably noticed, when assigning a table to a new variable using the equal (=) operator, only a reference to the table will be assigned to the new variable.
And Hollywood being based on Lua that makes sense. I don't remember which version it was though, but it is not the latest, so I guess many new Lua features won't work with Hollywood.
Re: Table1 = Table2, how does this actually work?
Posted: Tue Nov 26, 2024 11:50 am
by Flinx
emeck wrote: ↑Mon Nov 25, 2024 6:01 pm
it is also more or less what is explained in the
CopyTable() of Hollywood's help
Yes, but the behavior is different than for other data types, so it's not something you would necessarily expect.
It would be useful to mention that a table only disappears when the last reference to it is removed.
Re: Table1 = Table2, how does this actually work?
Posted: Sat Nov 30, 2024 10:43 pm
by airsoftsoftwair
Flinx wrote: ↑Tue Nov 26, 2024 11:50 am
It would be useful to mention that a table only disappears when the last reference to it is removed.
I can add it to the doc but I think that behaviour is the only sensible way. It would be very weird if table2 would suddenly disappear when table1 is set to Nil or assigned to a new value
Re: Table1 = Table2, how does this actually work?
Posted: Sun Dec 01, 2024 11:43 am
by Flinx
The behaviour is certainly correct, but I only understood it fully after reading the LUA documentation that emeck cited. So I think an explicit explanation might be useful.