Date: 2001-11-13 19:10:37
I heartily agree with the other boosters who have suggested
putting more detailed information into diagnostic messages.
I've used a system where we actually included the values
of relevant variables in the messages, as well as a brief
explanation of what went wrong, and that was very nice
information to have. However, in order for that to be
workable you need an easy, concise way to format the strings.
In boost.assert, perhaps it would be useful to factor out
the "how to format/log a string" part separately from
the "should we assert() or throw or die" part. Then
any code developed to do nice formatting could be
used in other places as well as for assert.
This discussion motivated me to finally upload some code
that I've been playing with for a while. It was originally
intended to make it convenient to nicely format the strings
that go into thrown exceptions, but I don't see any reason it
couldn't be used for assertions as well. The full header
is now in the boost files area under "error_message".
Basically it lets you say things like:
if( num_widgets > max_widgets )
BOOST_ERROR_MESSAGE << "num_widgets = " <<
num_widgets << " is greater than maxwidgets = " <<
(In our system we actually defined additional macros to make
common cases even more concise, but this gives you the general
The BOOST_ERROR_MESSAGE macro allows you to format a
message as though you were writing to cerr, meaning that
you can use iomanipulators and overloaded operator<<()
functions, and it also timestamps the string and labels it
with __FILE__ and __LINE__.
You can override the default behavior (for example, making
it log the message in a disk file) by defining another
macro that points to your own handler function. (The same
thing could be done with a sethandler if that method were
If folks think this might be useful I can write up some
more complete documentation on it. While actually putting
something like error_message into boost.assert might
constitute feature creep, it would seem reasonable to design
such pieces carefully to make them play nicely together.
- Michael Kenniston
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk