
On Tue, Jun 2, 2009 at 6:28 PM, Emil Dotchevski <emildotchevski@gmail.com>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.