Boost logo

Boost :

From: Mickaël Pointier (mpointie_at_[hidden])
Date: 2001-11-13 03:28:00


> However, I'm not sure I see the advantage in the extra functionality
> that is provided over the (standard) assert().

Displaying the name of the function/method that asserts, disabling the
assert, login all the asserts into a file and continuing are things I like
but are not present into the standard assert implementations.

> The extra functionality that can be provided in the error handler
> (e.g. throwing an exception, continuing etc.) can not be relied upon
> as the assertions will be disabled in the release build. In fact,
> allowing user code to be called in an assertion will lead to subtle
> bugs in release builds when such code is disabled.

It's not really user code, it's more "user handling of the assertion".
For me, having code into an assert is something like this:

    assert(handle=open_file(...),"file not open");

this is dangerous (and plain wrong since the open_file is removed
from release build).
But having the option that the user can extend assert functionalities
does not seems wrong for me. If he decides he needs additional stuff
it's certainly someone competent enough to know that he better have
to avoid heavy stuff that will alterate the behavior of the application.

 
> This just leaves the additional functionality as an aid to debugging,
> but that is surely just a quality-of-implementation issue. Under
> Windows,with VC++, the support for assert() is spectacular- in a GUI
> application a dialogue box is provided that (optionally) allows one
> to call up the JIT debugger and jump to the assertion with a full
> stack trace.

VC++ assert is not so spectacular.
First you can implement the same without too much difficulty, using
GUI or not, and it can be particularly usefull to have a smart assert
display that is able to not crash for application when poping on the
screen. If you ever try to run a fullscreen debug version of a direct x
game you will understand what I mean. (Using you own assert you
can switch back to windowed mode before breaking).
Second, when you choose to break using VC++ assert, you stop into
assembly code, and you have to step out of the assert code and
switch back to "source mode". Really nasty.

VC++ asserts looks like this:

    void assert_func(expression,message)
    {
        print message
        if (ask question())
        {
            __asm { int 3 }
        }
    }

    #define assert(expression,message)
            if (!expression)
            {
                assert_func(expression,message)
            }

of course with this method when you break you are in the middle
of alien code without debug info.

My own asserts does something like this:

    #undef assert

    #define assert(expression,message)
            if (!expression)
            {
                static bool flag_disabled=false
                if (!flag_disabled)
                {
                    print message
                    ask question())
                    if (answer_stop) __asm { int 3 }
                    if (answer_disable) flag_disabled=true
                }
            }

so far this type of behavior has been much more valuable
for me than VC standard assertion code.

assert is generaly good, but can be made better :)

    Mickael Pointier


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk