> What would the patch look like? Is this simply a new class, or does it > change existing API? Just a new class. the goal is not to change the existing API. At the moment it is not really a patch, just an independant class.
> If it's just a new class, I don't understand why it needs to be in > glibmm. Because, when I searched this feature, I expected to find it in glibmm (just a personnal feeling). But OK, if you think that such mechanism is useless to be provided by glibmm, you have (obviously) a better idea than me of what glibmm shall be. > If it changes existing API then it can't be allowed. This is a good rule ! > I haven't investigated the code at all. But I guess some response is > better than none. Le Mardi 10 Octobre 2006 09:44, Murray Cumming a écrit : > On Mon, 2006-10-09 at 22:36 +0200, Thomas Metz wrote: > > Thanks to your advices and remarks, I have updated the verbose_exception > > class with the execinfo gcc feature > > (http://tmetz.free.fr/verbose_exception-0.5-1.tgz). > > > > Unlike what I though, execinfo is independent of the debugger flag > > (execinfo is enabled with -rdynamic flag). So the stack info can be added > > with minimum size overhead (1 to 5 %). > > > > With this new version it becomes useless to add a macro at each function > > / method (in fact it is not fully equivalent because execinfo does not > > trace inline functions) > > > > So > > > > > > Inconvenients : > > > > - a VE_CATCH_RETHROW macro shall be added on all methods / > > > > > > This is practically a killer. No one (I think) will add this, it is > > > way too inconvenient and intrusive (and I guess also a performance > > > slower.) > > > > It is no more true. > > > > What's your new feeling ? As it can be really easy to add stack info, > > what about to add something similar in glibmm API ? > > What would the patch look like? Is this simply a new class, or does it > change existing API? > > If it's just a new class, I don't understand why it needs to be in > glibmm. > If it changes existing API then it can't be allowed. > > I haven't investigated the code at all. But I guess some response is > better than none. _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
