Re: assertions: does it matter that they are disabled in production?
marlow.andrew@googlemail.com wrote:
Assertions via assert.h (or cassert) are disabled in production and
have to be enabled via the NDEBUG macro.
Sorry, but that is wrong: You have to disable (not enable!) assertions with
the NDEBUG macro. Further, whether that is done in production code is up to
personal taste. I like them off in my production builds though, because I
need the speed more than the absolute correctness of the result, but I
don't program medical equipment or aviation devices either.
This is one reason I don't use the assert macro. I always throw an
exception that means a fatal programming error has occurred. Am I the
only one that does this?
How do you throw exceptions from a destructor? How do you throw them from a
signal handler or thread entry function which has C binding and therefore
must not throw? In any case, you are neither aborting cleanly nor are you
unwinding the stack to a place where the state is valid again. After all,
detecting a programming error, an unexpected inconsistency often means the
state of the program is beyond repair, so anything that still touches it
(like throwing exceptions) is likely to not make it better.
Also, but I don't know if you meant that, an exception doesn't automatically
mean a fatal programming error has occurred, exceptions are a perfectly
normal part of error handling.
My reasoning is that I always want the checks on, just in case. This
means it is something I tend to do sparingly, after all, loads of them
might well create a performance issue.
Right, lots of checks can create performance issues. However, you shouldn't
handle this as error handling but rather as a built-in diagnostic mode for
your code. For example, I have a parser table and my algorithm uses a
binary search that obviously relies on the table being sorted. Now, I don't
check each and every time when I look up a value that the keys are sorted.
Rather, I only do so when NDEBUG is not defined. The point is simply that I
am confident that the production and debug variants work the same, but in
the debug variant I check this using alternative algorithms or expensive
validation. You could call this a built-in unit test.
All the std programming text tell us how good it is to use assertions
(I am thinking of books like OOSC(II)) but the mechanism they describe
is like cassert every time, i.e turned off in production. I have
noticed that it is hardly ever used on any C++ projects I have seen.
It doesn't seem to get much use in C libraries either but does seem to
have a slightly higher usage there.
Well, lots of bad code are out there, in particular for languages that make
it damn easy to shoot yourself in the foot like C and C++. That is IMHO not
a reason why the language or in this case assertions are a failure, it's
just that people don't understand assertions or that they don't understand
their value.
Uli
--
Sator Laser GmbH
Gesch?ftsf?hrer: Thorsten F?cking, Amtsgericht Hamburg HR B62 932
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]