Julian Foad wrote:
> C. Michael Pilato wrote:
>
>> What are the differences between these two approaches? You noted
>> "possible data loss". How so?
>
>
> "assert(condition)" checks "condition" and aborts with a useful
> message - but only if the software is compiled in "debug" mode
> (usually by setting a preprocessor symbol "DEBUG" or "_DEBUG", or by
> not setting "NDEBUG").
No, actually DEBUG or _DEBUG never affect assert. Only NDEBUG does.
> When the software is compiled in "release" mode, the "assert" macro
> expands to nothing, so the condition is not even evaluated or tested.
>
> "if (!condition) abort();" checks the condition, and aborts if it is
> false, regardless of whether it is a debug build or a release build.
>
> Therefore "assert" is generally appropriate for checking conditions
> which, according to the design of the software, can never occur.
But if they do occur, you want an abort regardless of how you compiled
the code.
> Such conditions only occur when there is a bug in the software, and
> thus help to find the bug. If such a bug affects the user of a
> release build, the software will not abort at that point but will
> continue and have undefined behaviour.
Exacthy. And this is unacceptable, because /that/ could lead to data
loss or corruption.
> Hopefully it will soon abort due to dereferencing an invalid pointer,
> or will produce the wrong result and the user will notice and report a
> bug, or maybe it will go on to produce the right result for the wrong
> reasons, and the user will not notice.
Or it will go ahead and zap the user's 15000 revisions of history and
the user won't notice until it's too late anyway.
And I disagree with the idea that a "debug" version of the code do more
checking than a "release" version, except where it really does check
"can't happen" conditions. But even then I'm sceptical, although I have
put asserts here and there in our code.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 9 21:18:24 2004