There is no guarantee that finalizers will run before a program exits

[gen2brain]

This is from the SetFinalizer documentation:

There is no guarantee that finalizers will run before a program exits, so typically they are useful only for releasing non-memory resources associated with an object during a long-running program.

Here is how the author of Windigo solved this https://www.reddit.com/r/golang/comments/1lw1yei/comment/n2ccrt8/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

[mappu]

Thanks for trying Miqt! I'm a fan of your IUP bindings too.

Miqt uses Go finalisers for Qt functions that return objects by value. CGo can't express a C++ struct by value, only by pointer, so Miqt had to move all such objects to the heap. The purpose of the finalizers is so you can call QFoo.Rect(), get a "QRect" back, and then when the value gets GC'd, the finalizer will destruct the C++ memory. This makes the ergonomics look more similar to C++/Qt.

runtime.GC() calls are guaranteed to queue finalizers for all unreachable objects, and runtime.GC is called often throughout a Go program's life. It's true that a Go/Qt program can exit before all finalizers are executed, but in that case Qt is exiting anyway. So i think this "no guarantee of running" is probably OK in practice.

An arena allocator is interesting. It definitely solves the issue of not being guaranteed to execute.

As well as the arena allocator, some other possible ideas are

• If we're considering more manual memory management, is it really better than asking users to call defer QRect.Delete() manually? Go developers are used to it from (*os.File).Close() and everything else; or
• switch to runtime.AddCleanup (requires Go >= 1.24, has slightly different rules); or
• find a way to actually return all such structs by value (Project simple Qt types (QRect/F, QSize/F, QRgba64) as plain Go structs #79). I think this whole Finalizer business really does only happen for simple types returned by value.

[gen2brain]

I missed that runtime.AddCleanup somehow, it does seem to address all the limitations of runtime.SetFinalizer. And now it is not even the latest version of Go. I don't mind and even prefer to do everything manually, as long as every Delete is exposed and will not conflict with some automatic management.

I am planning to rewrite some old therecipe/qt app, and I am looking at options. Doing it with something else, like IUP, would mean a lot of work for something that Qt provides out of the box. Qt is really nice, and I am glad there are again maintained bindings, thanks.