Re: [boost] Interest check: Boost.Debug

Subject: Re: [boost] Interest check: Boost.Debug
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-06-02 19:28:10

On Tue, Jun 2, 2009 at 3:42 PM, Zachary Turner <divisortheory_at_[hidden]> wrote:
> 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?

Yes, the functionality would have to be implemented anyway, and you're
asking the right question: should this stuff be kept as undocumented
(inaccessible?) implementation details?

Keep in mind the implications of documenting it: support,
documentation and maintenance become more complicated. For example,
what if it turns out that the full interface can't be implemented on
platform X? With the simple to_string interface that's no problem,
since even return "stack trace unavailable" is a possible
implementation. Also consider the other possibility: what if the
platform X provides useful, platform-specific information that doesn't
fit the portable interface?

The string-based interface is so basic it that can easily accommodate
anything (but I admit that it isn't as cool.)

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

Provided I have a function that gets me a string that contains that
information, I personally don't have a use case for such iteration. I
can't think of what else I'd want to do with this data other than dump
it somewhere as text. Can you?

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