Re: failure due to compiler?

jgllgher@maths.tcd.ie says...
)>However, as expressions in C++ (and Eiffel) may have side effects, turning
)>assertion checking off may alter the behaviour of the program. One Eiffel
)>user I know claims to have experienced this perplexing behaviour. His
)>program worked as expected until he turned assertion checking off!


Dave Gillett <davidg@genmagic.com> wrote:
) The particular home-grown flavour of assertion-checking macro that I like
)has the "feature" of deliberately evaluating the tested expression *twice*.
)Code that relies on side-effects of such evaluation typically breaks while
)I'm still building debug versions.


jmccarty@sun1307.spd.dsccc.com says...
>Yes, that is a common flaw in <assert.h> implementations. DEC shipped
>such a defective <assert.h> until I complained. Here is one which
>I believe works. I typed it in just now, from a file which does work.
>But I may have made a little typo. The __VAL__ __STR__ thing is a
>standard trick used with the preprocessor to evaluate strings. Note that
>the predicate is evaluated exactly once.


    IT IS NOT A FLAW, IT IS A FEATURE.


    Since assertion predicates will not be evaluated in release builds, code
which relies on side-effects of assertion predicate evaluation will be broken.
Predicates without side-effects avoid any possibility of this happening.
    By evealuating the predicate twice, the implementor of assert() tries to
ensure that predicates with side-effects will break in the debug build. This
is preferable to a program which works fine in the debug build, but fails
mysteriously in the release build.
    (Recall that efficiency of debug builds is of even less importance than it is
of release builds. In my view, even in release builds, efficiency is less
important than correct program behaviour, and an implementation of assert() is
only as valuable as the reasons it provides for believing that the release
build will function correctly.)


    I didn't further explain that this is my own home-grown version of assert(),
with a couple of other things I like, too. Like a dialog box that gives me the
choice of aborting the task, popping into the debugger, or ignoring the failure
and continuing. Like a descriptive message instead of a naked/cryptic
predicate. Like a complementary form for those cases where it's easier to
construct a predicate that should be FALSE than one that should be TRUE.


Dave
[I agree, it's a feature. Clever hack. For the truly paranoid, perhaps
you could make the number of times it evaluates the condition settable at
compile time. -John]


--

Return to the comp.compilers page.
Search the comp.compilers archives again.