Boost logo

Boost :

Subject: Re: [boost] Interest check: Boost.Debug
From: Zachary Turner (divisortheory_at_[hidden])
Date: 2009-06-02 18:42:33


On Tue, Jun 2, 2009 at 5:26 PM, Emil Dotchevski <emildotchevski_at_[hidden]>wrote:

> On Tue, Jun 2, 2009 at 3:17 PM, Zachary Turner <divisortheory_at_[hidden]>
> wrote:
> > On Tue, Jun 2, 2009 at 5:08 PM, Emil Dotchevski <
> emildotchevski_at_[hidden]>wrote:
> >
> >>
> >> Adding stack trace support to Boost Exception was also discussed at
> >> BoostCon, it would definitely be a nice addition to the rest of the
> >> information recorded in Boost exceptions automatically by
> >> BOOST_THROW_EXCEPTION.
> >>
> >> I'm guessing that the stack trace information could be stored in
> >> boost::exception as a little more than just a list of pointers to
> >> functions, and converted to string at the catch site. Of course this
> >> support should be kept separate from Boost Exception, IMO a simple
> >> interface like this would be ideal:
> >>
> >> namespace boost
> >> {
> >> namespace debug
> >> {
> >> class stack_trace;
> >> shared_ptr<stack_trace> get_stack_trace();
> >> std::string to_string( stack_trace const & );
> >> }
> >> }
> >>
> >
> > I do agree that at a bare minimum it should provide a to_string()
> function,
> > but actually so much more than this is possible. The rudimentary support
> > for this that I've implemented so far already can determine how many
> > parameters a function has, its return type, the names of the arguments,
> the
> > types of the arguments, the values of each parameter. So it would
> > definitely be nice to provide iterators for these types of things, and
> > accessors / enumerations to determine what data type something is, names
> of
> > symbols, etc. This way (among other things, such as the file / line
> number
> > / overloaded new and delete issue I mentioned in the previous post)
> someone
> > could provide a custom formatter for a stack trace if they didn't like
> the
> > default.
>
> I can't think of a use case for wanting anything but a string, to be
> dumped into a bug report of some sort. You might need more than that
> if you want this interface to be powerful enough to implement a full
> featured debugger or whatever, but that's a different problem domain
> altogether. So I'd keep the stack trace interface simple and to the
> point.
>

Well, ok for the stack trace interface itself I can agree with that. Most
of the other functionality will end up getting implemented one way or
another though, otherwise it wouldn't be possible to generate a stack trace
in the first place. So would it be worthwhile to expose the other
functionality, even if through some other interface than a stack trace? For
example, the stack_trace class internally may need to create some objects of
type symbol which contain references to the module_info the symbol is
contained in, the name of the symbol, source/line number, virtual address,
etc. This interface could be exposed as well, since it's going to have to
probably be written anyway.

Also, I think it's useful to at the very least be able to iterate the stack
frames and find source/line number information for each call in stack.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk