Re: [boost] Interest check: Boost.Debug

Subject: Re: [boost] Interest check: Boost.Debug
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-06-02 18:26:22

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.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode