Tip:
Highlight text to annotate it
X
What I'm going to do now is read a short quote from Julian Seward,
the author of the Valgrind Tool.
If you haven't used Valgrind and if you're a serious C++ developer, you really should.
It's an amazing tool that runs dynamic checks on your running program.
and it looks for errors such as null pointer references,
out-of-bounds array accesses, and other things.
He said, "This code is absolutely loaded with assertions, and these are permanently enabled.
As Valgrind has become more widely used, they have shown they worth,
pulling up various bugs
which would otherwise have appeared as hard-to-find segmentation faults.
I am of the view that it's acceptable to spend 5%
of the total running time doing assertion checks."
So, what Julian is saying here is that he's going to cost everybody 5% of total running time
in order to make testing and debugging of Valgrind easier.
I've included this somewhat long quote because I really agree with Julian here.
I think it's generally worth our time to try to make our code fail early, fail fast,
rather than keeping going and failing in confusing ways later
or even providing people with completely wrong results.
On the other hand, let's imagine we're working at NASA or someplace like that,
and we're writing software that's going to be controlling a spaceship
as it lands on Mars or some other planet.
We have to ask ourselves the question do we want
to enable assertions checks for this kind of a mission?
I actually talked to a NASA engineer some time ago
who had worked on the software for one of the Mars missions.
What he told me was for most of the mission--
that is to say for the launch phase, for the cruise phase, for orbiting Mars--
they had plenty of assertions enabled in the actual mission software--
that is to say, in the software running on the spacecraft.
On the other hand, for a short period of time during which the spacecraft
was actually landing they disabled all of the assertions
on the idea that they got only one shot to land on the planet
and that if anything went wrong with the software during the landing process
it was better to just try to keep going,
because an assertion violation leading to a system reset
could cause the lander to become unstable
in such a way that it wouldn't have been recoverable.
That gives us a summary.
If you're doing something so critical that it keeps going that it resembles landing
a spaceship on Mars, then go ahead and turn off assertions in your production software.
Otherwise, you're probably better off leaving them enabled.