On Jun 1, 7:44 pm, Michael <mchlg...@aol.comwrote:
The EXE
will be in the debug/ or release/ directory (you'll probably want to
run the release build for your actual release).
You probably won't. In practice, you'll probably want to
develop your own list of options, which does something sensible.
The debug options that VS uses aren't really that bad, but the
release options turns off assert's, which means that you
definitly don't want to use them as is in code you deliver.
Clearly you don't get the concept of asserts. The whole point is that
you can put in all sorts of anal checks that are useful for you in
developing, but you never want the client to see.
Clearly YOU don't get the concept of asserts. They're like a
life jacket on a boot. Do you wear a life jacket when the
boot's in the harbor, and take it off when you go to sea.
For one thing, you may put in things that slow the program down a
lot. For example, I read that Excel has a version of its
recalculation engine that is really dog slow (several minutes to
recalculate), but is so simple it works every time, and their
production version uses all kinds of fancy algorithms to save time by
doing minimal recalculations (< 1 sec recalc time, typically). They
have various asserts where they run the dog slow version and the
production version and compare that the results match - you wouldn't
want to do that in the shipping version.
That's a rather extreme case. Especially given that an assert
must be a single expression, without side effects. Still, there
are times when the profiler says you can't. In which cases, you
do something like:
#ifdef PRODUCTION
#define NDEBUG
#include <assert.h>
// critical section...
#undef NDEBUG
#include <assert.h>
The assert.h header was carefully designed intentionally for
this, so that you could just remove the asserts from a single
function, without removing them from the rest of code.
For another thing, if an assert fails, the program crashes in a
particularly hideous way.
And if the condition occurs, and the assert isn't there? The
program crashes sometime later, in just a hideous way. Or
worse, it doesn't crash, and the user doesn't realize that the
results are wrong.
That is not at all appropriate for
production code - at a minimum you should crash cleanly and give the
user a cryptic error message ("An error of type 123 occurred. Click
OK.")
The usual solution here is to wrap the program in a small
script, which captures the error message AND the core dump, and
informs the user in whatever way is appropriate that the error
has occured. For the type of applications I work on, the script
usually restarts the program.
--
James Kanze (Gabi Software) email:
ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
