Memory leak?

I wonder if it is okay to do the following:

newImage=newImage(...) newEffect=newImage(...)

newImage.effect=newEffect

later in the code I do this:

newImage.effect=0 -- setting the effect to zero

Now I wonder if it is enough to remove the newEffect image to get it out of memory 100% by doing:

display.remove(newEffect) newEffect=nil

or do I have to do set this to nil instead of 0 like this:

newImage.effect=nil

I would like to know if it is okay to give table values other content without thinking about the content it had before, like images for example.

Can anyone please give me a hint here? :slight_smile:

Regardless if it’s a member of a table or a simple variable, each time you take a display object or anything that allocated memory and assign it to a variable, you are making a reference to that allocated memory. It will be freed up when there are no more references to it. References are removed by setting them to nil.  Assigning a 0 will not trigger the code that removes the reference to memory, so  you have to use nil. Then you can immediately set it to 0 if you need to. 

Rob

thank you for clarifying this Rob!

One more thing:

In addition to the question above and your answer… for example when I have used this for enemies locked to a weapon system and I want to unlock them I now do this:

Weapons[x].lockedOnEnemy=nil Weapons[x].lockedOnEnemy=0

Now I wonder if there could be a GameLoop cycle where somewhere in the code there could be a check for the Weapons[x].lockedOnEnemy and the check can catch exactly the nil value from above? Or is it safe to set the nil and instantly the zero after it?
 

It’s safe to nil and instantly 0. I don’t know why you would want lockedOnEnemy to be a display object at one point and a number at another. If you’re using for a test:

if Weapons[x].lockedOnEnemy then 

nil would be false, 0 would be true. Unlike C based languages, 0 isn’t false.

Rob

Thank you for the info Rob!

One more thing: When I’m targeting a new enemy as a locked on enemy… how should I do this when there is already one locked?

Let’s say we have this:

Weapons[x].lockedOnEnemy=enemy1

Should I lock to a new one like this:

Weapons[x].lockedOnEnemy=enemy2

or do I have to set nil first (because to delete the handle to the first locked one?)

Weapons[x].lockedOnEnemy=nil Weapons[x].lockedOnEnemy=enemy2

Regardless if it’s a member of a table or a simple variable, each time you take a display object or anything that allocated memory and assign it to a variable, you are making a reference to that allocated memory. It will be freed up when there are no more references to it. References are removed by setting them to nil.  Assigning a 0 will not trigger the code that removes the reference to memory, so  you have to use nil. Then you can immediately set it to 0 if you need to. 

Rob

thank you for clarifying this Rob!

One more thing:

In addition to the question above and your answer… for example when I have used this for enemies locked to a weapon system and I want to unlock them I now do this:

Weapons[x].lockedOnEnemy=nil Weapons[x].lockedOnEnemy=0

Now I wonder if there could be a GameLoop cycle where somewhere in the code there could be a check for the Weapons[x].lockedOnEnemy and the check can catch exactly the nil value from above? Or is it safe to set the nil and instantly the zero after it?
 

It’s safe to nil and instantly 0. I don’t know why you would want lockedOnEnemy to be a display object at one point and a number at another. If you’re using for a test:

if Weapons[x].lockedOnEnemy then 

nil would be false, 0 would be true. Unlike C based languages, 0 isn’t false.

Rob

Thank you for the info Rob!

One more thing: When I’m targeting a new enemy as a locked on enemy… how should I do this when there is already one locked?

Let’s say we have this:

Weapons[x].lockedOnEnemy=enemy1

Should I lock to a new one like this:

Weapons[x].lockedOnEnemy=enemy2

or do I have to set nil first (because to delete the handle to the first locked one?)

Weapons[x].lockedOnEnemy=nil Weapons[x].lockedOnEnemy=enemy2