Boost logo

Boost :

From: Darren Cook (darren_at_[hidden])
Date: 2003-05-23 03:02:17

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");

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 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.


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

                case 'd': case 'D':
                        // retry
                        // don't know how to break...
                        std::cout << "Don't know how to break into debugger..." << std::endl;
                        bContinue = true;

                case 'a': case 'A':
                        // abort

                        bContinue = true;

                if ( !isspace( ch) && bContinue)
                        // ignore spaces
                        std::cout << "\nChoose option: I - Ignore, D - Debug, A - Abort" <<

        // 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, gregod at, cpdaniel at, john at