Re: when we can delete a class derived from Gtk::Window or others

Den 2022-02-18 kl. 18:55, skrev Klaus via gtkmm-list:
>
>> I tested you example and it works whenever the user closes the 
>> windows in the reverse
>> order from creation.
>
> That it seems to work is known. The question is, is it the allowed way
> to do this? If the Gtk::Window class performs more actions after hide()
> and access data for the current class, the code has undefined behavior,
> even if it works in the moment. I simply could not find any
> documentation which gives me an idea what the window class perform on
> close action.
>
Several of the example programs in the gtkmm tutorial delete a 
Gtk::Window in a "hide" signal handler. See e.g.
https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/blob/gtkmm-3-24/examples/book/menus/main_menu/exampleapplication.cc

https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/blob/gtkmm-3-24/examples/book/printing/advanced/printformoperation.cc

In the examples I've found, the deletion is not done by the window 
itself in an overridden default signal handler. It's done in a connected 
signal handler. I'm pretty sure it doesn't make a difference.

I would say it's safe to delete a Gtk::Window in a "hide" signal 
handler, default or connected. I ran the main_menu example with 
valgrind, both as it is on the website, and with "delete this" in an 
overridden default signal handler. valgrind did not report any illegal 
memory accesses.

Kjell