Access Violations and Illegal Instruction Errors
------------------------------------------------
If you're getting an access violation or illegal instruction error when 
you run your program, the most likely causes are:

  - you are accessing an array an a physically invalid index.
  - you are accessing an array at a cell that has not been
    initialized.

For the former, check every loop you use to process an array, and make
sure that you don't have any obvious errors, like:

  const int MAX = 100;
  ...
  string City[MAX];
  ...
  for (int Idx = 0; Idx <= MAX; Idx++) {  // <-- error!
     City[Idx] = "No Name City";
  }

For the latter, just make sure you write code to initialize every cell of 
each of your arrays to hold some recognizable dummy values.


"Program runs incorrectly on Curator but not on my machine..."
---------------------------------------------------------------

Sometimes when the Curator indicates that your program crashed, hung, 
produced incomplete output, or produced incorrect output, you may find 
that running your program with the same input on your machine produces 
correct results and no crash.  That may happen for a number of reasons, 
including:

  - you may be running Windows 9x.  Test your program in the lab.
  - your program may have an error that's dependent on the contents
    of memory, which varies from machine to machine.  In this case,
    you've failed to initialize something, probably the tail end of
    one of your arrays.
  - your program may have an error that's masked by Visual... this
    is the nasty case...


Visual C++ IDE and Program Testing
----------------------------------

There are two types of ways to build a program in Visual C++:  debug build 
and release build.  The default is a debug build:

In a debug build, the compiler adds code (a LOT of code) to your program 
to help the debugger analyze your program.  In theory, that shouldn't have 
any effect on how your program runs.  In practice, it does.  I've seen many 
cases where the debug build for a program will execute correctly even 
though the program contains serious logical flaws.  The problem is that the 
added debug code changes the way your program behaves, sometimes to the 
extent that certain errors are masked or even eliminated.

In a release build, the compiler just produces the code that corresponds to 
the source code you wrote (well, mostly).  So, if your program is flawed, 
running the release build will generally make that apparent.

When the Curator compiles and links your program it does so from the NT 
command shell (see section below).  This is not exactly a release build, 
but it doesn't incorporate any of the debug code that you'd get by default 
if you did a build from within the Visual IDE.

Why do we do it that way?  Mainly because no one involved in the Curator 
project has figured out (yet) how to duplicate the default debug build 
from the command line.  But, also, because we don't really want to.  The 
debug build can mask flaws in a program and we want to find those flaws 
(and fix them, of course).

So... if the Curator indicates your program is incorrect, but you don't 
see the same errors when you test your program on your machine, what can 
you do?

First of all, you can try doing a release build -- you'll almost certainly 
see the same errors then that the Curator saw.  How do you do a release build?


How to do a Release Build in Visual C++
---------------------------------------

Go to the Build menu, and select the "Set Active Configuration..." item.  
You'll see a dialog window listing two choices.  Click on the choice for 
Win32 Release and then on OK.

Now just do a build as usual and run your program.

Note:  if you do a release build, many of the features of the Visual 
Debugger will not be available.  It's sort of a Catch-22 situation... 
if you do a debug build you don't see the error... if you do a release 
build you have to debug it by examining your output and your code and 
using diagnostic output statements you add to figure out what's going 
wrong where.


How to do a Command-line Build in NT/2000
-----------------------------------------

You probably will not need to do this at all... and this is not a 
tutorial on the NT command shell.

Open a command shell (Start/Programs/Command prompt).

Navigate to the directory where your cpp file is stored.  If you 
don't know how to do this, ask someone to show you.

At the command line, type the command "vcvars32.bat" and press return.  
This sets certain environment variables.

Then, at the command line, type the command "cl /nologo /GX <your source 
file name".  For example, "cl /nologo /GX p9.cpp".  (And press return, 
of course.)

This will execute the compiler and then the linker on your source code.  
Any error or warning messages will be displayed to the command window.  
If the build is successful, your executable will be in the same directory, 
named something like "p9.exe".

To run your program from the command prompt, just type the name of the 
executable, say "p9.exe".

This is exactly how the Curator compiles and executes your program.