|
Boost : |
From: Darren Cook (darren_at_[hidden])
Date: 2003-05-23 03:02:17
Hi,
I tried this out, and it is looking good (gcc 3.2 on linux).
> Example:
> SMART_ASSERT( (i < j) || (i < 0) || (k == -1) ) (i)(j)(k);
>
> After the expression, you'll specify all the values that were involved in
> it,
> surrounded by (), like this: '(i)(j)(k)'
Actually you can specify any values in current scope, not just in the
expression being asserted. E.g.
FILE *f=fopen(fname,"r");
SMART_ASSERT(f)(fname);
Is this officially supported or could it disappear in future?
> - debug: a summary of the assertion is printed, and asks the user
> what to do (Ignore/ Retry/ Abort/etc.)
Can Retry be called "(D)ebug"? (and as you already use "D" perhaps detailed
info could be called "(M)ore Details"?).
Retry suggests to me I can put the missing file in place and it will try the
fopen() call again.
Also if cannot break into debugger I think:
bContinue = true;
is more useful than abort().
BTW, I quickly found that I always wanted detailed output, so I made a
ask_user_on_assert_console_detailed() function, which I've included at the
end of this mail. I also did the two proposed changes above. Can this
function be included? (but I think the briefer version should stay as the
default.)
> Default logger dumps all details of the assertion to
> a file called './asserts.txt'.
As someone else said I think I'd rather I had to specify the filename if I
wanted this logging.
> So far, it contains the __FILE__ and __LINE__ (and __FUNCTION__, if
> present).
Function name not appearing on linux. Do I have to do anything to enable
this, or is it not supported for gcc yet?
> 9. Custom printing (NOT TESTED YET).
> You can set your own printer class.
Do you have an example of how to do this?
> SMART_VERIFY behaves ***exacly like*** SMART_ASSERT, with two differences:
> - SMART_VERIFY will work in release mode as well
> - the default level of SMART_VERIFY is 'error'.
> Which means that if a SMART_VERIFY fails, an exception will be thrown
> by default. This makes sense, since the assertions you use in release
> could most likely be fatal.
I feel it should be the other way round - when I'm debugging I'm happy for
an assert to kill the program, but if something asserts in the bug-free (!)
runtime version I'd rather it quietly log it and try to continue - the
assert may be a false alarm.
However I'd almost certainly be explicit about assert behaviour if using
SMART_VERIFY in any serious program so the default is not so important.
Darren
----------------------------------------------------
inline void ask_user_on_assert_console_detailed( const assert_context &
context) {
// show info to the user
std::cout << std::endl;
dump_all_assert_context( context, std::cout);
// read
std::cout << "\nChoose option: I - Ignore, D - Debug, A - Abort" << std::endl;
bool bContinue = true;
while ( bContinue) {
bContinue = false;
char ch = std::cin.get();
switch ( ch) {
case 'i': case 'I':
// ignore
break;
case 'd': case 'D':
// retry
#ifdef BOOST_BREAK_INTO_DEBUGGER_DEFINED
break_into_debugger();
#else
// don't know how to break...
std::cout << "Don't know how to break into debugger..." << std::endl;
bContinue = true;
#endif
break;
case 'a': case 'A':
// abort
abort();
break;
default:
bContinue = true;
break;
};
if ( !isspace( ch) && bContinue)
// ignore spaces
std::cout << "\nChoose option: I - Ignore, D - Debug, A - Abort" <<
std::endl;
};
// FIXME - do ignore_all;
// note: I will assume there is ONLY ONE assertion per line
// (reasonable assumtion), in order to be able to have
// 'Ignore All'.
}
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk