[prev in list] [next in list] [prev in thread] [next in thread]
List: gtk-devel
Subject: Re: [gtkmm] C & C++ exceptions, FAQ 4.6
From: gtkmm mailing list account <gtkmm-list () bernard-hugueney ! org>
Date: 2003-11-08 11:31:18
[Download RAW message or body]
Bonjour,
Le Samedi 8 Novembre 2003 03:16, Owen Taylor a écrit :
> On Thu, 2003-11-06 at 12:56, gtkmm mailing list account wrote:
> > ( Hoping CC to gtk-devel-list is appropriate )
snips
> > would only be a matter of "quality of implementation" : if your
> > Gtk+ library was compiled with gcc and the -fexceptions flags,
> > your exceptions will be propagated, otherwise, you will be warned
> > at runtime.
> >
> > If the Gtk+ configure script sets this flag, I have no doubt
> > packages would follow.
> >
> > I don't see any downside in setting this flag when possible, and
> > it might be useful, so why not ?
>
> You can't throw exceptions back through GTK+. As an obvious
> example, GTK+ does:
>
> g_object_ref (object);
> g_signal_emit (object, "clicked");
> g_object_unref (object);
>
> (The ref/unref actually happens inside g_signal_emit().) So
> throwing an exception from a signal inevitably leaks memory. There
> is all sorts of other internal state you'll corrupt causing
> subsequent misbehavior and crashes.
Damn C :-) ! I'so used to put unrefs in desctructors I didn't think
about it :-( I guess it's not possible to do better in ANSI C (hence
the __attribute__ cleanup extension of gcc).
Back to gtkmm, maybe a word or two in FAQ item 4.6 could explain why
it's not possible to do better (inability of GTK+ C code to do proper
cleanup during unexpected stackunwinding).
Thanks for the explaination.
Bernard
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic