Re: [gtkmm] C & C++ exceptions, FAQ 4.6
- From: gtkmm mailing list account <gtkmm-list bernard-hugueney org>
- To: gtkmm-list gnome org, gtk-devel-list gnome org
- Subject: Re: [gtkmm] C & C++ exceptions, FAQ 4.6
- Date: Sat, 8 Nov 2003 12:31:18 +0100
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]