Re: assert vs. std::logic_error?
On Nov 24, 3:32 pm, "Alf P. Steinbach" <al...@start.no> wrote:
[...]
Another argument against asserts in production code is
performance: asserts significantly slow down the program (if
they don't you haven't used enough asserts in your code).
Sorry, that's mostly bullshit, in the technical meaning of
bullshit. A slowdown due to assertions means you're using
assertions incorrectly, to check too complicated stuff.
Actually, it's more of a misleading half-truth. The reason you
don't use assertions to check too complicated stuff is precisely
because they'll slow things down. Imagine a function which
processes a large set of data, with a post condition that the
data are sorted. I'd certainly like to assert that post
condition, since it's part of my contract. I don't, of course,
because verifying that a large array is sorted *is* too
expensive to leave in production code.
What's probably needed is some sort of multi-level assertions,
depending on run-time, so that you can turn off the expensive
asserts, and leave all of the rest in. Ideally, anyway---in
practice, with a little care, I've never had any real problems
with the current situation.
Namely that there is a runtime cost associated, an engineering
trade-off, and so you really want to have an assertion system
in place where you can shut down the most costly ones.
Checking costly-to-compute invariant of data structure all the
time isn't meaningful after that class or set of classes has
been debugged and tested, but leaving more inexpensive asserts
in place is meaningful, because it can catch remaining logic
bugs.
Exactly. The most important assertions in production code are
generally pre-condition checks. Which are generally not too
expensive.
Of course, it also depends on the application. I've worked on
some very critical applications (locomotive brake systems, for
example), where we did verify the invariants after each
operation. If there's the slightest chance of an error, we want
to detect it immediately, and crash, so that the back-up can
take over. And this behavior is considered critical enough that
if it means paying more for a faster processor, you do it
anyway.
--
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