[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtkmm
Subject:    Re: Arbitrary number of child windows
From:       Chris Vine <chris () cvine ! freeserve ! co ! uk>
Date:       2008-05-12 23:01:29
Message-ID: 1210633289.3219.36.camel () boulder ! homenet
[Download RAW message or body]

On Mon, 2008-05-12 at 18:23 -0400, Paul Davis wrote:
> well, things may have gotten much better than they were (much of my
> experience here was rooted in gtkmm 1.2), but basically destroying a
> widget while inside a method connected to a signal (on some other
> widget) was an invitation to disaster. random disaster, of course,
> because of the delightful way that memory allocation on *nix systems
> works. it still seems a bit rude to me to say:
> 
>    foo.signal_bar().connect (mem_fun (*objptr,
> Object::do_something_then_delete_me));
> 
> i think that in general, signal_bar() would like to know that the
> handlers it is calling do not destroy the objects they are invoked
> upon. 
> 
> maybe these assumptions are all gone now.

At the C/GTK+ level this is OK.  The OP was concerned with dialogs, and
the destructor of Gtk::Window (via Gtk::Window::destroy_() and
Gtk::Window::destroy_c_instance_()) will call gtk_window_destroy() on
the underlying GtkWindow/GtkDialog object, which is fine, as it will
correctly finalise all its contained widgets and its own underlying
GObject.

I do recall a problem with libsigc++ 1.2 at < 1.2.3 blowing up if a slot
method deleted the object of which it was a method but that was
corrected in version 1.2.3 (and never affected 1.0 or 2.0/2.2); that did
prevent calling 'delete this' in the circumstances you describe:

2002-12-11  Tim Shead  <tshead@k-3d.com>

        * sigc++/signal.cc: Fix segfault when a signal observer deletes
        itself from within its signal handler.

Chris


_______________________________________________
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
[prev in list] [next in list] [prev in thread] [next in thread]