Re: Testing Program Question
On Feb 13, 1:00 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* Leigh Johnston:
Asserts are a sort of life jacket, to prevent things from
fucking up too much when you screwed up. Removing them
from production code is akin to wearing a life jacket when
practicing in the harbor, but taking it off when you go to
sea. Sometimes, it's necessary to remove asserts for
performance reasons, and for some particular applications
(games?), it's probably preferrable to remove them
completely (in which case, you do have to study what
happens when they are removed---there's no point in
removing an assert if you're just going to get a crash
three statements later).
I disagree, why do you think assert was designed to do
nothing for NDEBUG? Asserts were designed to be used as a
debugging tool so should do nothing in released production
code *unless* a higher degree of defensiveness is required.
I disagree that only games are an exception, I would also
argue that such defensiveness is not required for a typical
office application for example (e.g. a word processor). The
amount of software which requires less defensiveness
probably outnumbers the amount of software that requires
increased defensiveness. If you are worried about cosmic
rays hitting your ram chips then perhaps you should use
assert more! :)
I think one main problem is that NDEBUG is binary.
Partially, at least. You can define and undefine it as often as
you want in code, and include <assert.h> after each change, but
1) it's overly verbose, so not used as often as it should be,
and 2) you can still only include <assert.h> at global scope, so
the maximum granularity you can get is that of a function.
Some asserts are very costly (e.g. think about asserting that
a list is sorted, or an assert at the very lowest level of
code): you want to only optionally enable them, have them off
by default unless you suspect some problem.
Agreed. There are potentially asserts that you'd like to put in
that are expensive enough that you'd like to activate them only
if you actually had a problem.
Some asserts have mostly acceptable cost: you want to leave
them in if possible, unless profiling or simple measurement
show that some specific such are too costly.
Some asserts have essentially zero cost because they're simple
checks at mid or high level of call chains, you want to keep
them enabled anyway as belt & suspenders defensive
programming.
I'm not sure, but three general assertion levels sounds about
right (haven't thought about this earlier).
If you offer three, someone's going to want four:-). But yes,
your analysis sounds about right.
--
James Kanze