From: John Torjo (john_at_[hidden])
Date: 2003-05-25 02:58:07
> > Example:
> > SMART_ASSERT( (i < j) || (i < 0) || (k == -1) ) (i)(j)(k);
> > After the expression, you'll specify all the values that were involved
> > 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?
True! It is as of now on ;-)
First of all, I thought of allowing that only for ENFORCE - when I'll do it.
But now, it should be ok with SMART_ASSERT/SMART_VERIFY as well.
> > - 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
> info could be called "(M)ore Details"?).
Anyway, you should know that you can have your own handler, an show whatever
you like to the user...
> Retry suggests to me I can put the missing file in place and it will try
> fopen() call again.
True... I used the M$ convention. My mistake ;-)
> Also if cannot break into debugger I think:
> bContinue = true;
> is more useful than abort().
TRUE! Thanks. Done.
> 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.
Indeed. It will be possible. I'll soon post an update.
> > 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?
Now I use the BOOST_CURRENT_FUNCTION.
> > > 9. Custom printing (NOT TESTED YET).
> > You can set your own printer class.
> Do you have an example of how to do this?
Not yet :-(
But I will show one, when doing the documentation.
> > SMART_VERIFY behaves ***exacly like*** SMART_ASSERT, with two
> > - 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.
Indeed. So, if you want the failed assert to quitely log and continue, just
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk