Table & Indexes

[Virox]

Hey

I've got a question about tables.
I've got a tableA with 10 objects inside it. But these object come and go constantly (table.insert & table.remove)
When you remove ex: object 5, objects 6 till 10 lower one index so the index of object 10 shifts from 10 to 9.
So far no problem.

But i've other tableB with references to the index in tableA... so when object 5 is remove in tableA and there is a reference to object 10 in table A it will point to a none existing value because 10 is now 9.
Is there a way to catch this shift? Either by stopping the shift or by updating the references. But both solutions aren't ideal in my opinion. Are there other solutions?
I'm thinking about having a global variable to keep track of number object EVER created and adding this number as an extra attribute and use it as an alternative index to reference to.

[kikito]

Do you really need to store indexes in TableB ?

Why don't you store references to the objects themselves?

Code: Select all

TableA = {'a','b','c','d'}

TableB = {a=TableA[0], b=TableA[1]}

Now you can use TableB.a and TableB.b to reference the 'a' and 'b' values, even when they are removed from TableA.

[subrime]

Except that this code is *copying* the values, not referencing.

Your example will only work (as references) if the elements of TableA are themselves tables.

[bartbes]

Lua NEVER copies a table, always uses references.

[Virox]

Do you really need to store indexes in TableB ?

Why don't you store references to the objects themselves?

Code: Select all

TableA = {'a','b','c','d'}

TableB = {a=TableA[0], b=TableA[1]}

Now you can use TableB.a and TableB.b to reference the 'a' and 'b' values, even when they are removed from TableA.

Doesn't a Lua table starts to count by 1 instead of 0?

TableA = {'obj1','obj2','obj3','obj4'}

TableB = {a=TableA[1], b=TableA[2]}

So when i do table.remove(Table1, 2) obj2 get's removed from tableA and this remains -> TableA = {'obj1','obj3','obj4'}
What will happen to the references in tableB?
TableB => nil (because it was removed)
TableB => obj3 (because the table has filled up the gap? And shifted the tableindexes)

Hopefully for me the answer will be nil.
I would have tested it myself but I'm currently not working on a pc with Love installed
Thanks for all the answers.

[kikito]

Doesn't a Lua table starts to count by 1 instead of 0?

Mm.. probably. I try to avoid using integers on my tables as much as I can. When I do, I create the tables inline (t={a,b,c}) and then parse them with ipairs(t) ... so I never have to track 0s and 1s!

Code: Select all

TableB[b] => nil (because it was removed)
TableB[b] => obj3 (because the table has filled up the gap? And shifted the tableindexes)

That code isn't correct. We are using strings on TableB, so you have to say TableB['b'] or, more easily, TableB.b.

I believe TableB.b will return obj2, even if obj2 was removed from TableA. We are storing a reference to the object, not to its index (and as someone has mentioned, in some case we store a copy of the object - like with strings and integuers).

For it to work the way you want, you would have to store integers on TableB, and obtain objects by using those integers on TableA. Then, it also depends on how you remove elements from TableA:

Code: Select all

TableA = {'obj1','obj2','obj3','obj4'}
TableB = {a=1, b=2} -- storing indices on TableB

TableA[TableB.a] -- returns 'obj1'
table.remove(TableA,1) -- removes obj1 from TableA, "shifting" all other objects to the left
TableA[TableB.a] -- returns 'obj2'
TableA[1] = nil -- removes obj2 from TableA, but just making it nil (not recommended, because ipairs will stop working)
TableA[TableB.a] -- returns nil

[Virox]

Thanks for correcting and helping me out.
I think I'll figure out a way now.

[bartbes]

Simply put you never have a real table anywhere, only references to the memory assigned by lua, so, when you unset one reference the other reference is not empty, only when all references are gone lua will destroy the object.
Furthermore, the statement that this isn't the case for strings is incorrect, it should (haven't tried it, but it has been written that this is the case) point to the same internal string object. So

Code: Select all

a = "something"
b = "something"

would mean that both a and b are a reference to the same data.