Re: [boost] Interest check: Boost.Debug

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

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

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

Well, if you're saying that iterating over the frames to get source/line
information when the to_string() already contains formatted source/line
information is unnecessary since one could implement a parser to extract it,
then eh, I'm not sure.  It would be undesirable to be tied to a specific
output format for fear of breaking someone's code that uses a parser to
parse the output.  The iteration need not necessarily be provided by the
same interface.  I mean your stack trace interface could be:

class stack_trace
{
public:
      stack_trace();
      ~stack_trace();
      std::string to_string();
};

and you could have another class defined:

class stack_frame_iterator
{
public:
     stack_frame_iterator(const stack_trace& trace);   //begin()
     stack_frame_iterator();  //end()
};

which at least separates the two.

The main use case I had for knowing source / line information I described in
my second post in this thread.  In short it allows a more powerful
implementation of the __FILE__ and __LINE__ pre-defined compiler macros.  If
you wanted to provide an overloaded global new/delete to, for example,
provide cross platform memory diagnostics then __FILE__ and __LINE__ are
insufficient since they would point inside the implementation of the
operator.  With stack frame iteration your operator new / delete could
simply create a stack trace, move backward 1 level, and what you end up with
is the equivalent of a __FILE__ / __LINE__ for the previous function, which
is the only thing that would be helpful in that case.  It could always store
the entire stack trace instead of just the file / line that allocated the
memory but that might be wasteful from a memory / performance standpoint.