Re: Arbitrary number of child windows



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.





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]