Dann Corbit said:
When code is compiled in release mode, an assert() call does nothing at
all. If an assert() fires, then code was delivered to a customer
without having NDEBUG defined at compile time.
So the burning question is, why is debug code being delivered in the
first place?
There can be situations where it simply isn't possible to do
rigorous testing before delivery. I am often writing code for
controlling lab equiment that's far too expensive to have
around (beside not having room to put it nor, in some cases,
the necessary supply of LN2 or LHe2 to operate it;-). And
there's not enough time (and money) for doing in-depth tes-
ting on-site. So the customer understands that there probably
still will be bugs in the code, both due to me getting it
wrong or the manuals for the equipment not being correct and/
or complete (which happens quite a lot, unfortunately). And
since bad code can, at least in some situations, damage the
equiment I very much try to err on the side of having the
program trigger an assert() than having it do something that
may be very expensive to repair if I got it wrong...
Thus I put asserts in the code in all kinds of places I am
in principle convinced of they never can be reached and have
a framework in place that sends me an email with a backtrace
if an assert() is triggered anyway. That way the customer
and me both benefit - I get a rather reliable indication of
what went wrong, the customers equipment doesn't get damaged,
s/he gets an error message that stands out plus I can quickly
react without him/her having to explain what exactly they were
doing at the moment the assert() was triggered (which is often
very hard to figure out without a backtrace or lots of trial
and error to reproduce the exact same conditions). And I tend
to leave the asserts in even if after some time nothing unto-
ward happened since a) I never can be sure how much of the code
has really been used and thus tested and b) a replacement device
with new firmware may behave differently in unpredictable ways
from the original one.
Of course, that could be seen as a mis-use of asserts, but
then they're simply convenient to use and the time spend on
checking asserts is negligible compared to the time spend on
waiting for devices to react (and the code is also littered
with all kinds of tests for other things that could go wrong
and asserts are just an emergency break if nothing else caught
the problem before, i.e. the cases that I assumed to be impos-
sible but were not 150% sure).
Regards, Jens