Re: Assertion vs Exception Handling
On Mar 16, 12:50 am, "Leigh Johnston" <le...@i42.co.uk> wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
[...]
How's that that C and C++ folks always worry about
performance, while Java folks don;t worry? All my apps run
with debug builds and asserts and are lot faster then Java
apps. If you got the point ;)
:-)
Most C++ folks don't worry that much about performance. Or
rather, they only worry about it in the few places where it
counts. And judging from the many companies I've worked
with, it's extremely rare to ship code compiled with
optimization turned on or asserts turned off.
(Of course, there are times when speed is critical, and in such
cases, you do what you have to do.)
I think you will find that a lot of C++ programmers do care
about performance,
Far too many do unnecessarily. But as i said, when it is
important, you do what you have to. I've worked on a lot of
hard real time applications, where responding too late to an
event is a fatal error.
Such applications aren't the majority. Even in embedded
systems, today, it's often cheaper to use a more powerful
processor than for programmers to optimize. (But in practice,
politics generally enters into such decisions.)
I do, games programmers certainly do, embedded programmers
probably do especially when the CPU is not all that fast. It
is woolly thinking to release products with optimizations
turned off due to some silly sense of non-existent risk - put
more trust in your compiler. You can have asserts in
optimized code - worst that can happen is that a line number
in the assertion report might be misleading or the the assert
affects performance but common sense should dictate where you
place such assertions (e.g. before a loop rather than in a
loop).
That is, more or less, what I've been saying. You don't have
just two modes: debug and release. You have a large gamut of
possibilities. Including disactivating asserts in the critical
portions, but not elsewhere. Or activating some of the checking
in the standard library, but not all. Or using different levels
of optimization. In most of the places where I've worked
before, performance wasn't an issue: I was working on large
scale servers, reliability was critical, and if it wasn't fast
enough---the program only ran one one or two machines, so you
just upgraded them (from say 32 cores to 256). Today, the
programs run on literally thousands of machines, and some of the
functions take between 20 minutes and an hour to execute. So we
do deliver with maximum optimization (even if this means finding
work-arounds for the compiler bugs, since VC++ doesn't always
call all of the necessary destructors when optimization is
stepped up), asserts disabled, and anything else which can help
speed done. In fact, we're currently moving to three modes,
since that's what makes sense in our environment.
The whole point is that the defaults don't do you a whole lot of
good. None of our builds correspond exactly to what Microsoft
offers as the defaults for "debug" or "release" modes.
--
James Kanze