How to get your code to compile

A long time ago... computers used relays instead of circuits. These relays would go up and down, and up and down, and generally create a lot of heat. So in the summer, the computer room would get quite hot and the programmers would have to leave the windows open. Insects would get in and plant themselves in the relays and get squished. After a while the computer would start having errors and the programmers would have to literally get in and de-bug the computer. We don't have relays anymore but somehow those bugs find a way in!

THE COMPILER BUG:
any of an order (Hemiptera and esp. its suborder Heteroptera) of insects that have sucking mouthparts, forewings thickened at the base, and incomplete metamorphosis and are often economic pests -- called also true bug

Before you Compile (The EMACS "window-screen")

Properly used, EMACS can screen out many potential bugs before they hit the compiler. The more bugs you catch before you actually compile the happier you will be.

Colorize EMACS: EMACS can colorize your code and show you which words are variables, it can mark strings, comments and more. Kind of like a simple silent compiler that compiles as you type! To set it up, simply copy the file ~escobj/public/emacs from my directory to your home directory and then rename it .emacs. Notice the . before the emacs.
```
      cp ~escobj/public/emacs ~/.emacs 
```
Should do it. Now the next time you call up emacs, it will colorize any of your .C or .c files. It works best if you call up your file at the command line prompt:
```
      emacs project1.C &
```
line-number-mode: It is a good idea to place EMACS into line number mode. This way when you get a compiler error you can easily scroll to that line number. To set it up, put the cursor in the EMACS window and press ESC once. Type x. Then type line-number-mode followed by ENTER. You will be able to see the line number at the bottom of the EMACS window.
TAB: Lastly, by hitting the TAB key in EMACS, it automatically aligns your C++ statements. This will also help you find parse errors, like missing semi-colons, and will make your code look neater.

Time to Compile (The G++ "bug-swatter")

Inevitably bugs will make it through your pre-compiler "screens" and rear their nasty heads. This is how they look when viewed under g++:

oddeven.C: In function `int main()':
oddeven.C:8: parse error before `>'

The first line tells you which function the error is in. In this case the error is in the main function main(). The second line has a number. This number is the line number that the error is occuring in. Finally, an often cryptic message follows trying to describe the nuisance.

What G++ says and what it means:

unterminated string or character constant = You didn't match quotes
`cout' undeclared (first use this function) = you mispelled or left out #include <iostream.h>. Same with `cin' and `endl'.
Parse error before `>' = you left out a ';' or mismatched '(' or '{'
`x' undeclared (first use this function) = you didn't declare `x' e.g. int x;
parse error at end of input = You don't have enough '}'s or didn't match them correctly

Notes:

Try to attack bugs one at the time, starting with the first one that occurs. Some bugs have a loud bark but little bite. That is, one bug, like the parse error, may cause a large number of other bugs to occur after it. Often by cleaning these little buggers up you can decrease your bug occurance dramatically.
Compile with the -Wall option. This will make g++ very sensitive. Not all bugs are "show-stoppers". Sometimes the compiler will skip over bugs if it thinks it knows how to handle them. To enable the -Wall option:
```
     g++ -Wall -o doom doom.C 
```

Exercise 1:

Copy the file bugged.C from my public directory and get it to compile.

After you Compile (The XXGDB Exterminator)

So you think you got all the bugs out? Wrong. You only got the weak ones the compiler could detect. The logic bugs and the dreaded Seg Fault bugs easily slip past the compiler "bug-swatter".

Now it's time to bring out the heavy guns. To use xxgdb, you must first compile with the -g option:

      g++ -g -o bugged bugged.C

Then issue the command:

      xxgdb bugged

Now you will see a window that is split in three sections, with the top half containing your source code, the middle half containing many buttons, and the bottom all this text garbage. Now go to the top half and click on a function that you want the program to stop at. In this case, we only have one function, main(). After you click on it, click on the "break" button in the middle section of xxgdb. Then press "run" and wait.

Soon a little red hand will appear with a blue arrow showing you that the program has run and now has stopped at the first point it could after the "break". Click on the "next" button and you will see the arrow move through your program. When you get to "cout", you will see the text appear on the bottom section of xxgdb. When you get to "cin", you will have to enter a number. Enter it in the bottom section of xxgdb.

Click on one of the variables, 'x'. Then click on the button, "display". You will see a tiny window appear on the bottom that says:

1: x = <The number you typed>

This will aid you immmensly in the future when you have big programs with loops and you want to keep track of your variables. In fact, if you are having problems with your first programming assignment, you will want to run xxgdb on it to see exactly what your loops are doing.

Now you should be able to step through the rest of the program by pressing "next".

Why doesn't the loop work?

Exercise 2:

Find the logic bug and fix it.

(I didn't include any Segmentation Fault bugs in this. You'll find plenty of those yourself when you start using arrays and pointers)

<---- TAKE ME BACK TO CS1

John Escobar