Re: verbose exception

[Thomas Metz <tmetz free fr>]

> 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.