Memory management for nested classes

snoopdouglas

This question is more of a sanity check than anything else, but I just wanted to check whether if I were to do this with a nested class:

class Nested:
  var x: int
  func _init(nx: int):
    x = nx

func make_nested() -> Nested:
  return Nested.new(2)

...would the returned Nested need to be free()'d, just as with any other un-memory-managed Object?

If not, I'm guessing that it'd be wise for me to add extends Reference to the nested class to prevent leaks. Is this a pattern anyone else has used?

TwistedTwigleg

I would recommend extending Reference, as then it should be reference counted by Godot and freed when there is nothing using it. That said, I am completely suggesting this based on assumptions rather than actual experience with this kind of thing (I haven't used nested classes in Godot at all), so I would take my advice with a rather large grain of salt :lol:

snoopdouglas

Great. I wanted to make sure of this because (for reasons I can't explain) I had this idea in my mind that nested classes are passed by value, or automatically reference-counted, or something. Also, oddly, I hadn't seen Godot complaining about a leak on exit (like it does if I forget to queue_free() a node).

I wonder whether it'd be worth showcasing extends Reference in the docs for inner classes, because I've never thought to call free() on them!

snoopdouglas

Apologies for bumping this, but I've just discovered this is completely unneeded so wanted to make sure the correct info is here for anyone who stumbles across it.

It's actually briefly mentioned in the docs that scripts implicitly extend Reference. This also applies to inner classes, though. I just made sure of this by explicitly adding extends Object to an inner class, and sure enough, leaks were detected on shutdown:

WARNING: cleanup: ObjectDB instances leaked at exit (run with --verbose for details).
   At: core/object.cpp:2132.

So, to be clear, extends Reference isn't normally needed.