On Mon, 2008-05-12 at 22:16 +0100, Chris Vine wrote: > On Mon, 2008-05-12 at 16:34 -0400, Paul Davis wrote: > > if you're in a signal handling call stack, i can't agree with this. you > > have no idea which, if any, members of a Glib::Object and all of its > > derived classes might still be accessed after your handler method > > returns. > > Can you unpack that for me? I have never had any problems > destroying/finalising GObject objects in a signal hander. (I am not > asserting there can't be problems, but I have not come across them - or > is this specific to glibmm?)
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. _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
