From: Rob Stewart (stewart_at_[hidden])
Date: 2002-12-26 12:22:48
From: "Peter Dimov" <pdimov_at_[hidden]>
> From: "Rob Stewart" <stewart_at_[hidden]>
> > We find it invaluable to provide explanatory text along with the
> > expression that failed. We often build strings -- at runtime --
> > that provide additional context information and description in
> > the message.
I should point out that in my particular situation, we don't mind
our applications coming to a crashing halt. However, we need to
determine very quickly what's wrong and get them going again.
Thus, having a lucid and detailed explanation of the error
condition is important.
> Interesting perspective. The question that springs to mind is: would you
> abandon your ASSERT macro in favor of BOOST_ASSERT_MSG, if it existed? Why
> would you want to do that? IOW, what is the intended audience of
> BOOST_ASSERT, Boost library developers or "end users"?
I'm sorry this reply is so late, but it's here finally.
If there was a cross-platform, flexible, and helpful facility
available from Boost to replace what we currently use, I would
certainly work to replace existing code with Boost's. The
reasons are that it would encourage knowledge of Boost and it
would have a good chance of becoming standard C++ in the future.
I see no reason to retain and maintain code that duplicates
what's available from Boost when we can make the replacement
So, what is the intended audience of BOOST_ASSERT? I think all
C++ code, in Boost and in application code. Can a single
facility work equally well in both environs? Yes. I can say
that because we have assertion macros (and machinery behind them)
that are used by library and application code. (The library code
is used by various applications throughout the company, serving
many different purposes, so don't get the idea that it is really
application level code.)
The difficult question is how to reconcile the message type you
require with the dynamically generated messages I mentioned.
Obviously, if BOOST_ASSERT could take a std::string or
std::ostringstream as easily as a char const *, then we're in
business. IOW, if BOOST_ASSERT merely passes its message
argument to boost::assertion_failed(), and
boost::assertion_failed() could be overloaded to take different
parameter types for the message argument, then the BOOST_ASSERT
client can supply different message types and corresponding
boost::assertion_failed() overloads. Does that seem reasonable?
A capability like that would also make converting to BOOST_ASSERT
easier. The reason is that our macro could be a simple wrapper
for BOOST_ASSERT as an initial step toward complete conversion.
-- Rob Stewart stewart_at_[hidden] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk