Everyone should start with the same source code as set up in the previous Task

the Debugger

Here is some information about the Debugging environment you'll need to know.

You can ask the program to execute one step and halt so that you can look at things.
This is called stepping through the program.
You will learn this process first and later learn some more fancy ways to get to program to start in a certain place and run to a certain place and other things.

REAL PROGRAMMERS USE DEBUGGERS

MAKE SURE YOU CAN USE THE DEBUGGER.

There are several basic ways to step through a program while in debugging mode:

• Step Into [F11]
• Step Over [F10]
• Step Debugging [SHIFT-F5]
• Continue [F5]
• Step Out [SHIFT-F5]

These behave quite differently.
When you learn more about functions, you will understand more about the differences. For now, just learn how to use these kinds of stepping tools.

STEP OVER [F10]

Think of Step Over as "execute this statement then stop" (or more precisely "execute this statement but don't go to the details of how it works and after doing it, then stop".

In order to get the computer to execute your statement:
cout << "hello";
you'll Step Over [F10] this statement.

You'll use Step Over [F10] to go through your program one statement at a time pausing after each statement is executed and looking at what changed. Values stored in variable might have been changed - you can check if they did change. Output in the console window may have changed - you can check to see that it did. A user may have entered some values and these should have been placed into variables - you can check that this did happen. You will use the debugger to check that what you told the computer to do really did what you wanted it to.

STEP INTO [F11]

Whenever you start a program it begins with the first statement in the main() function.
What would happen if you asked the system to Step Over the main() function? It would execute your program completely without showing you the details. That's not what we want to see. We want to see the main function's statements being executed one by one so we can look at the results of that execution.

The first thing to do to step through your code is to Step Into your code [F11]. After that, you'll mostly be doing Step Over [F10].

STEP OUT [SHIFT-F11]

Step Into can sometimes take you into code that you will be very scared of!
It's not really scary like it will destroy your work or your computer. It's only scary to beginning programmers who have never seen anything like it.
To avoid getting into these scary places, you'll mostly use Step Over [F10] instead of Step Into [F11].

If you do get into scary code, use Step Out [SHIFT-F11] to get out.

Step Into is really telling the Debugger to go somewhere else in the executable file, execute some (probably scary) code and come right back so that it seems like you just executed one statement. Recall that cout << "hello"; causes hello to appear on the screen. You type this statement into your source code when you want to write hello on the console window. How it is actually written pixel by pixel is that other (scary) code. The code for the details of how to write things in the console window is part of the IDE and was linked to your program by the linker so it really is part of your executable file but you didn't write it and it has scared many first timers. If you find yourself looking at code that you don't know anything about, that you didn't write, you'll need to bail yourself out. Sometimes it is an easy task and other times, not. You'll use Step Out [SHIFT-F11] to get out of the code you didn't want to be in. You may have to use Step Out [SHITF-F11] a couple of times to get back to your code. Until you have a bit more experience with the debugger if , just ask for help.

STOP DEBUGGING [SHIFT-F5]

Sometimes you want to end your step by step session. To this you will use Stop Debugging [SHIFT-F5]. This ends the debugging session.

CONTINUE [F5]

Sometimes you don't want to end but you want to stop doing things step by step and run the rest of the program as if you were not debugging. That is Continue [F5].

Now that you know the basics, let's go.

Remember to stay together.

To start the debugger:

Debug|Step Into
or
hit F11

You should see the debugger in action now. The program will be recompiled and relinked - this time with the debugging things to allow us to single-step.

MAKE SURE YOUR SCREEN LOOKS LIKE THE FOLLOWING GRAPHIC. If it doesn't, ask for help.

1. The program is compiled and linked with the extra debugging code, the main() function is Stepped Into and there is an arrow at the left hand side indicating the next statement that will be executed.
2. All execution is paused at this moment so that you can look at the status of the console window (it's either behind the IDE of minimized - find it).
3. You can also look at the contents of all your variables. The Locals tab shows variables defined in main() (since main() is currently being executed). The Autos and Watch 1 tabs show memory in other formats. Select Autos to see that it too is empty. Empty? What is going on here? Didn't you define some variables inside the main() function? Why are they not appearing? Because you have gotten to their definitions yet. You have only just now stepped into the main() function.
4. It's time to execute the next step. That will be the first statement inside the main() function. Notice the several buttons that have appeared. Move your move over them and read the tool tips to learn which is Step Into, Step Over, and Step Out. (Sometimes Step Out will get you out of scary code and back to your safe and familiar program.)

DO NOT GO ON UNTIL THE LAB HELPER SAY TO

We want to see the results of executing the next statement. Do you want to Step Into or Step Over? (do you want to go into the details or not go into the details?) (A: Not go into)

Debug|Step Over
or
hit F10
or
click the correct button for Step Over

MAKE SURE YOUR SCREEN LOOKS LIKE THE FOLLOWING GRAPHIC. If it doesn't, ask for help.

Notice what has happened:

1. All of the comment lines were skipped. Comments are discarded by the compiler.
2. The yellow arrow indicating the next statement that will be executed is
   cout << "Programmer: John Q. Student" << endl;
   You know this is the actually the first statement but for some reason it wasn't executed when you did your first step into. What did happen is in item 2.
3. All variables local to the { and } of the main()function are now listed in the Locals window. Notice that they all have the names (the identifiers) and types you told the compiler to give them. What is odd is that they seem to have values stored in them but only some of them were initialized when you defined them - and those don't have the values you gave them anyway. What are these values called - the value stored in an uninitialized variable? Garbage! A good programmer must never use the value of an uninitialized variable. What's really going on here is the scope of the block of the main() function's body, its { }, has now been set up. You'll learn more about scope later.

DO NOT GO ON UNTIL THE LAB HELPER SAY TO

Execute the next step.
Will this be a Step Into step or a Step Over step?
(It better be a Step Over or you will be looking at some scary code! If you want to look at that code, you can - but please don't do it now during this recitation.)

1. We've moved the windows around a little so that you can see what happened in the console window.
   Hopefully the literal string you asked the computer to display is there now.
   What happened to the " " characters?
2. The cursor in the console window is at the start of the second line of output. Why?
3. The yellow arrow is pointing at the next statement that will be executed.

At this point you should be able to use the debugger to step through the statements of your code until all the identification output has been done.

Nothing but the console window and the position in the editor window should change.

Keep Stepping Over [F10] until you see the statement:

int num1, num2;

Stop there. The yellow arrow will be pointed at the line after this one.

Your screen should look like the following and the console window should have all the output:

MAKE SURE YOUR SCREEN LOOKS LIKE THE FOLLOWING GRAPHIC. If it doesn't, ask for help.

It seems something is different. You were not able to stop on the definition statement.
The way this IDE works is that that definition was set up when the main() function was first entered.

What you should notice is that right now, BEFORE the first assignment, the value of num1 is garbage.
What will happen when the assignment
num1 = 12;
is executed?
Will memory change?

As you choose Step Over, look at the variable named num1 in the Locals window.
You may have to click on the Locals tab at the bottom.

Did it change?

This IDE shows changes that just occurred in memory in RED in the Locals window.

Who changed that value in memory? You did - or the program did since that was what you told it to do.

Predict what will change when the next statement is executed and then Step Over to see if you were correct.

Here's an important thing to notice: The OUTPUT did not change.
Assignment does not affect the console window.

In the next line to be executed, what does << num1 << mean?
It means look up the current value in the memory named num1 and use that value in place of num1.
That's like having written << 12 << since the value of num1 is 12.

If you had only looked at the console window but you saw the number -2434 appear instead of 12, how could you know what might be wrong unless you used the debugger to see what should have displayed: the current contents of num1?
Using the debugger is the only way to know exactly what's in your variables at any step along the execution of your code.

What should the sum of num1 and num2 be? Look at what is currently stored in num1 and what is currently stored in num2. The sum of those values should be displayed by the next line of code as the value of the expression num1 + num2.
If you had only looked at the console window but you saw the number 98031 appear instead of 17, how could you know what might be wrong unless you used the debugger to see what should have displayed? Unless you know exactly what is stored in those two variables at this particular moment in execution, you can't really be sure what should be displayed.
Using the debugger is the only way to know exactly what's in your variables at any step along the execution of your code.

Hopefully you are now getting the hang of using the debugger.

Suppose that you need to stop the debugger for some reason.

Debug|Stop Debugging
or
SHIFT-F5
or
click the button for Stop Debugging

Start debugging again.

Use Step Into [F11] to start the program in step mode.

Then step through your program by Step Over [F10] until the statement about to be executed is:

double num3 = 123.4, num4 = 567.8;

Keeping stepping until your screen matches the following graphic. The yellow arrow should be positioned on the line we are interested in and the output window should be filled with all the ID info.

MAKE SURE YOUR SCREEN LOOKS LIKE THE FOLLOWING GRAPHIC. If it doesn't, ask for help.

What happens when variables are initialized when they are defined?

Can you predict how memory will look after this line of code?
Step Over and see if you were right.

Well you were probably close.
The precision of these values look odd.
This is due to the inability to completely accurately store decimal fractions as binary numbers.
Just to see if things are really serious, Step Over the next statement and look at the output.

It looks like the presentation is OK. Unless we need to work at very large precision, double will work for real numbers.

Now let's see how input and memory interact.
Hit Step Over [F10] until you seen the line pointed at in the next graphic. The yellow arrow should be pointing to this line (note that the graphic does not show this correctly).

Predict how memory - the contents of your variables num5 and num6 - will change as the user types on the keyboard.

Notice that since there is only one statement that does input and the debugger runs one complete statement at a time we will not be able to see the contents of the two variables change separately.

Until both inputs are entered, the program will not continue. After typing in the first value, try hitting two or three Enter keys and hitting the tab key a few times and also hit the space bar some. The program is waiting for all the inputs that are after cout << to be completely finished before going on.

Also remember that the person who is typing on the keyboard is NOT the programmer. It the programmer pretending to be the user.

Hit Step Over and pretend to be the user until both variables have changed

The console window comes to the foreground because the program can't continue until the input is done.
Below is the console window after I had typed 2734, hit Enter twice, hit the tab key five times, and hit the space bar three times, then then typed 8934.
Why are the contents of the variables num5 and num6 unchanged at this point?

Finally I have hit the return key after the 8934 and look at the changes in memory. (You do NOT hit F10 or F11, the system was waiting for the user's input in order to finish the input statement.)

If you had plaved the return 0; statement at the end of the main function, you need to recall that it is OPTIONAL and that good C++ programmers would not put it there. Don't waste your time on a test writing it.

But, suppose you did have the return 0; statement. Then carefully read the next few statements. They won't apply if you correctly did not put return 0;.

Keep stepping through your program using Step Over [F10] until you are about to execture the statement return 0; .

Should you Step over, Step into or Step out at this point?
You most definitely do NOT want to see how the run time system cleans up after itself!
Step Into will take you into that code so you do not do that.
Choose Step Over.

Notice that the program did not simply end. You are at the closing } of the body or block of the main() function. Recall back when you did your very first Step Into to start this whole process, you did not go directly to the very first statement. What happened was that the body or block of the main() function was set up first. That was actually setting up a scope. You may not know much about scope yet (you will later!) but the rules of C++ state that any variables defined in a scope must go away at the end of the scope. We are staring at a closing } . That means the end of the scope for all the variables defined inside the { and } . The debugger must stop here since that is the next step. You won't actually see this step since it's the very last thing done by the program, though.

What should you choose? Step Over, Into, Out?
None of these.

What is needed now is a sort of "keep going without having to exit the debugger but not doing any of the three Steppy things" direction. That's Continue.

Debug|Continue
or
F5
or
hit the button for Continue

Choose Continue and watch the Output window to see what happened.

1. This code still has the debugging additions so if you plan to make a millions dollars selling this code, you should rebuild it without the debugging stuff. (How to do that was done in rec01 - how to build an exe file, not how to make a million dollars.)
2. What value was "returned" to the runtime system?
3. No one quite knows where in the source code the editor will be placed!

You should now be familiar enough with the debugger to predict the change in the contents of memory and console window at each step of your program.

Do it. Start the debugger now and step through the entire program looking at your variables and console window and predicting what should happen. If anything happens you do not expect, try to figure it out and then ask a lab worker if you are correct.

Stop after you have executed the executed the return 0; statement by Step Over [F10].

Now let's look at some scary code and see how to get out of it.

Although you know you should normally do Continue [F5], for now do Step Into.

ARGH!!! Your screen will most likely look a little different than this.
How to get out of this?
Step Out [SHIFT-F11]

Try that now.

ARGH!!!
We are still in horrible code!
Actually the program has Stepped Out of the main function and the program has ended.
Notice the there are several open files now. Click the tab for your program - there it is. Click the tabs for the other code. There they are in all their horribleness. What to do now? Just close those files.

Click the tab for one of the files and then click the X in the upper right hand corner to close it.
Do this for each file that you don't want to be looking at.

Ahhh. Now we can work on our program some more (unless you closed it! - if you accidentally closed your own code, double click it's name in the Source Files folder in the Solution Explorer panel (at the right).

You are now done with rec02.
You can go back over any of this recitation at any time.

Return to the rec02 if you wish