about variables and "nil"

[d2gp]

Hi

This is a pointless bit of code, but apart from that,  is there anything wrong or potentially dangerous with the following?

t = 5 t = nil t = 6

I’m asking because my app has several different activities from which the user can choose via a main menu. The code for each activity is in its own lua file, as a giant table. When a user is done with one activity and returns to the menu, I nil out all of the variables that were in use in that activity. When the user returns later to it, the same variables get re-used. I’m not sure that this is a good way to approach this, but I’m wondering if there’s actually anything wrong with it.

thanks,

David

p.s related question: is it possible to have a dangling pointer in Lua? What if I did this. Would “b” be a dangling pointer?

a = {1,2,3} b = a -- b[1] = 1 a = nil -- could b[1] now be changed in some unpredictable way?

[torbenratzlaff]

Hey d2gp,

I assume you are using local variables in the examples above.

If that’s the case, you can use and reuse a single variable as much as you like. You don’t even have to nil it out before you override it. Additionally, if the execution of a block is finished (e.g. a function, a loop etc.) all local variables inside are cleared automatically.

So yes, your first example is perfectly fine, you might even skip the t=nil part.

You second example is fine too. Variables in LUA are just pointers to a specific place in the memory. So in your case:

a = {1,2,3} --'a' points to a table b = a --'b' points to the same table as 'a' does a = nil --'a' no longer points to the table, but that has no influence on 'b'

One thing to keep in mind is that if all references to a table are cleared, which would happen i you set an b=nil too, the table itself will also be cleared.

Read further on variales and blocks here:

https://www.lua.org/pil/4.2.html

[d2gp]

hi - 

Are my variables local? Sort of. Each module has a local table that contains all the variables for that module. So the variables can be used globally within the module, but are not actual globals. 

I see that doing t = nil in the first example is completely redundant. In my app, some of the variables/tables need to be reset after each time the module is played, otherwise they might still be holding stale values or data from the previous round, the next time the module is played. I’ve been nilling them out but it may be that I can clear their values or re-initialize them some other way.

Thanks for clarifying that the 2nd example is OK. So what exactly is   a = nil  doing?  I was wondering if it was deallocating the memory used for a, which would result in b being a dangling pointer, but I guess you can’t have dangling pointers in LUA because you can’t explicitly free or allocate memory, am I right? If you say myVar = nil , does it make the value formerly referred to by myVar  unreachable and therefore qualified for garbage collection?

thanks.

[torbenratzlaff]

Well, hard to say without knowing your exact setup.

If you declare your variable somewhere like…

local t

…than it’s local.

As I said, variales are just pointers. If you nil out a pointer, the memory it points to remains untouched as long as there are other pointers pointing to that exact same piece of memory. Meaning, that if you remove all pointers to a specific piece of memory, that piece is no longer reachable and therefor will be freed.

So a=nil only means, that a does not point to any memory any longer. As I mentioned above, you are right. If there’s no pointer/reference to a specific piece of memory, that memory gets freed by garbage collection.

[torbenratzlaff]

Hey d2gp,

I assume you are using local variables in the examples above.

If that’s the case, you can use and reuse a single variable as much as you like. You don’t even have to nil it out before you override it. Additionally, if the execution of a block is finished (e.g. a function, a loop etc.) all local variables inside are cleared automatically.

So yes, your first example is perfectly fine, you might even skip the t=nil part.

You second example is fine too. Variables in LUA are just pointers to a specific place in the memory. So in your case:

a = {1,2,3} --'a' points to a table b = a --'b' points to the same table as 'a' does a = nil --'a' no longer points to the table, but that has no influence on 'b'

One thing to keep in mind is that if all references to a table are cleared, which would happen i you set an b=nil too, the table itself will also be cleared.

Read further on variales and blocks here:

https://www.lua.org/pil/4.2.html

[d2gp]

hi - 

Are my variables local? Sort of. Each module has a local table that contains all the variables for that module. So the variables can be used globally within the module, but are not actual globals. 

I see that doing t = nil in the first example is completely redundant. In my app, some of the variables/tables need to be reset after each time the module is played, otherwise they might still be holding stale values or data from the previous round, the next time the module is played. I’ve been nilling them out but it may be that I can clear their values or re-initialize them some other way.

Thanks for clarifying that the 2nd example is OK. So what exactly is   a = nil  doing?  I was wondering if it was deallocating the memory used for a, which would result in b being a dangling pointer, but I guess you can’t have dangling pointers in LUA because you can’t explicitly free or allocate memory, am I right? If you say myVar = nil , does it make the value formerly referred to by myVar  unreachable and therefore qualified for garbage collection?

thanks.

[torbenratzlaff]

Well, hard to say without knowing your exact setup.

If you declare your variable somewhere like…

local t

…than it’s local.

As I said, variales are just pointers. If you nil out a pointer, the memory it points to remains untouched as long as there are other pointers pointing to that exact same piece of memory. Meaning, that if you remove all pointers to a specific piece of memory, that piece is no longer reachable and therefor will be freed.

So a=nil only means, that a does not point to any memory any longer. As I mentioned above, you are right. If there’s no pointer/reference to a specific piece of memory, that memory gets freed by garbage collection.