Re: when we can delete a class derived from Gtk::Window or others
- From: Kjell Ahlstedt <kjellahlstedt gmail com>
- To: Klaus <zfrdh web de>
- Cc: "gtkmm-list gnome org" <gtkmm-list gnome org>
- Subject: Re: when we can delete a class derived from Gtk::Window or others
- Date: Sat, 19 Feb 2022 12:42:57 +0100
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]