|
Boost : |
From: Ted Byers (r.ted.byers_at_[hidden])
Date: 2002-06-13 21:55:37
"Neal D. Becker" <nbecker_at_[hidden]> wrote in message
news:x88ofegznbw.fsf_at_rpppc1.md.hns.com...
> I'd like to have assertions that include a stack traceback. Is it
> possible to do this portably? Does such a lib already exist?
Neal, you started this. How about giving us your take on what the
functional requirements are? Fernando has described two alternatives for
dealing with trace information, and there has been a little discussion of
these, and ways of implementing either, but before we can really get a sense
of where to go, we ought to have some agreed set of functional requirements
we can use to assess the available options. Otherwise we may get lost in a
sea of discussions about our different tastes in how things ought to be
done. If we can agree on some set of functional requirements, we can then
proceed to objectively appraising each offered solution to see just how much
of our collective wish list can be realised in a reasonable amount of time,
and which items on our wish list might need to be sacrificed for the sake of
expediency.
What concerns led you to ask about this? How do you see it working? How do
you see the options Fernando mentioned fitting into this?
using your program see happening?
effectively? What information should be provided, and in what form? How
should release mode and debug mode behavior compare?
I am sure there are other issues I haven't mentioned.
I find my traceable exceptions of value, since the only time I am interested
in a trace is when something goes awry, in which case, or at least for the
more serious cases, I'll have an exception to deal with, and my traceable
exceptions will tell me what led up to the problem. But there are some
warts in my prototype, and there are some things I'd like that I don't know
if they are a) possible, b) practicable or c) how to actually do it.
For example, I want to refine my prototype so that I can guarantee that my
exceptions can be constructed and thrown without themselves generating a new
and significantly different exception. For example, if I have thrown a
traceable floating point exception, I don't want to throw a bad allocation
exception from one of the strings, or a different exception from the
ofstream when the trace information is supposed to be dumped to a file. But
to deal adequately with this, I'll have to learn a lot more about streams
and strings, and may possibly have to write my own, stripped down string
class.
And I am sure that there are other warts in my prototype, and would
appreciate hearing both about what they are and how they can be fixed.
But hey, my code is intended to be rather ordinary, standard C++, and so
should be quite portable; and if it provides the required information, in
the right circumstances, go ahead and adapt it for your purposes (I'll be
putting up, or rather sending to Schobi to put up, a revised version of my
prototype shortly: http://www.hschober.de/code/).
Cheers,
Ted
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk