Re: How do you debug?
On Oct 3, 1:04 pm, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
James Kanze wrote:
On Oct 2, 9:34 pm, Puppet_Sock <puppet_s...@hotmail.com> wrote:
On Oct 2, 4:56 am, Michael DOUBEZ <michael.dou...@free.fr> wrote:
[snip]
Actually, keeping asserts in the release code (i.e. not
using NDEBUG) is a good idea; just like wearing a safety
belt after you have learned how to drive.
You will find a lot of people who disagree with that.
You'll also find a lot of people who think that the world is
flat.
Really? I never found one. :-)
Question of milieu. If you frequent a milieu where geography or
astronomy are unknown, you'll find them. If you frequent a
milieu where software engineering is unknown, you'll find people
who believe you should take asserts out of deliverable code:-).
I've never seen a professional who disagreed.
Certainly there are many situations where it is just
unacceptable.
Such as?
One fundamental question is whether there is a notion of
"correctness" for the behavior of the program. Whenever
correctness of the results matter, I would hope that asserts
are left in so that in case of a bug that causes the state of
the program to be unforseen (and therefore potentially bogus)
there is a chance that it will crash. Few things are worse
than output that is believed to be correct but isn't; that can
be very costly, too.
Compilers are an example: I prefer a compiler crash to the
generation of potentially faulty object code any day.
On the other hand, there are programs where correctness is not
that meaningful a concept. Think of a game. The physics engine
may sometimes not detect that two objects are at the same
place at the same time or the rendering may be a little off
due to rounding errors or arithmetic overflows. Now, those
effects might be gone after two or three frames and as long as
the user experience is good, there is a reason to prefer the
game going on to the game crashing. In that case, it could be
a correct business decision to eliminate the asserts in
release code.
I'll admit that games are a special case with regards to
software engineering, and obey very different rules. There are
probably also a few other cases, that I'm not familiar with
either. But you've doubtlessly seen enough of my postings to
know my predilection for hyperbole (which I alternate with
typically gallic litote to really confuse people).
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34