C++ is a Strongly Typed language

1. CS 294-73 (CCN 27241)Software Engineering for Scientific Computinghttp://www.cs.berkeley.edu/~colella/CS294Lecture 4: Skill Development: Debugging

2. C++ is a Strongly Typed language • Strong refers to the fact that • a) there is checking being done • b) it happens at compile time • Typed means that all mixtures of data types has a well defined programmatic interpretation. Usually, most type mixing is just disallowed. • The following program gets a compiler error, what error? intmain(intargc, char* argv[]) { FArrayBox a; IntVectSetb; int result = a+b; return result; }

3. compilation 1 test1.cpp:6: error: ‘FArrayBox’ was not declared in this scope test1.cpp:6: error: expected `;' before ‘a’ test1.cpp:7: error: ‘IntVectSet’ was not declared in this scope test1.cpp:7: error: expected `;' before ‘b’ test1.cpp:8: error: ‘a’ was not declared in this scope test1.cpp:8: error: ‘b’ was not declared in this scope The compiler doesn’t know what these strange strings mean. It is telling you that there needs to be some declaration of what FArrayBox means

4. Fixed Program 1 #include "FArrayBox.H" #include "IntVectSet.H" #include "IntVectSet.H" intmain(intargc, char* argv[]) { FArrayBox a; IntVectSetb; return a+b; } • Get’s further….. • test1.cpp: In function ‘intmain(int, char**)’: • test1.cpp:9: error: no match for ‘operator+’ in ‘a + b’ • Some languages will accept this, what will happen ? • Why could I include the same header twice ? • What was the compiler looking for now ?

5. Compiler Warnings • A compiler warning indicates you've done something bad, but not something that will prevent the code from being compiled. • You should fix whatever causes warnings since they often lead to other problems that will not be so easy to find. • Example: Your code calls the pow() (raise to a power) library function, but you forgot to include <cmath>. • Because you've supplied no prototype for the pow() function (its in <cmath>), the compiler warns you that it assumes pow() returns an int and that it assumes nothing about pow()'s parameters: • somefile.cpp:6: warning: implicit declaration of function `intpow(...)' This is a problem since pow() actually returns a double. In addition, the compiler can't type-check (and possibly convert) values passed to pow() if it doesn't know how many and what type those parameters are supposed to be. • Note: The compiler will label warnings with the word warning so that you can distinguish them from errors. • You would be amazed at how clever a compiler can be about trying to consider an error to be just a warning

6. Compiler Errors • A compiler error indicates something that must be fixed before the code can be compiled. • Examples: • You forget a semi-colon (;) at the end of a statement and the compiler reports:somefile.cpp:24: parse error before `something' • You miss a closing } in your code: unexpected end of file • Always remember to fix the first few errors or warnings, since they may be causing all the rest. Compiler messages usually list the file and line number where a problem occurs. Nonetheless, errors often occur on the lines prior to what the error message lists. Especially check the line immediately preceding where the error message indicates. • Finally, note that some compilers may choose to call something an error while others may just call it a warning or not complain at all.

7. Linker Errors • If you receive a linker error, it means that your code compiles fine, but that some function or library that is needed cannot be found. This occurs in what we call the linking stage and will prevent an executable from being generated. Many compilers do both the compiling and this linking stage. • Example 1: You misspell the name of a function (or method) when you declare, define or call it: void Foo(); intmain() { Foo(); return 0; } void foo() { // do something } so that the linker complains: • somefile.o(address): undefined reference to `Foo(void)' that it can't find it.

8. Run-Time Errors • Run-time errors only occur when you run a program, and thus, they can only occur if there is a program to run (i.e., it must have compiled and linked without errors). • When you run the executable and something goes wrong then we call it a run-time error. There are two main types of run-time errors: • Fatal Errors • A fatal error is basically when the executable crashes. • Example 1: The program divided by zero, as in: • int scores = 500; int num = 0; intavg; avg = scores / num; The • program would crash saying: Floating exception • Example 2: Segmentation faults, Bus errors. • These occur when you try to access memory that your program is not allowed to use or that doesn't exist in the computer (i.e., there is only so much memory in the computer).

9. Strong Typing and Interpreted code • Interpreted Code: Everything is a Run-Time Error • Some interpreted code can be compiled. This often does not reveal these errors though. { FArrayBox a; IntVectSetb; int result = a+b; return result; } • Strongly Typed code often report errors as Compile Errors

10. More Segmentation Faults • Example: Using an uninitialized array index... int values[10]; inti; cout<< "The ith value is: " << values[i] << endl; • maycause such an error. These, particularly, are tricky since they may or may not occur based on what the initial garbage value of the index is when you run the program. Remember, you cannot generally assume variables get initialized to zero.

11. Logic Errors • A logic error occurs when your program simply doesn't do what you want it to. • Example: You have an infinite loop because you did not update the variable(s) used in the condition of a loop, as in: cin >> account_num;// Assume user did not enter -1. while (account_num != -1) { cout<< "Account #: " << account_num << endl; ProcessAccount(account_num); // Oops...Forgot to read another account here! } • Narrow down where in the program the error occurs. • Get more information about what is happening in the program. • Both techniques can be applied either with or without a debugging utility.

12. Debuggers • Tools to help you find and fix Run-Time errors • There are almost as many debugger programs as there are languages and libraries. • But deep down, they are all doing the same thing • A debugger is a program that you run • It uses the ptrace library to attach itself to another running program • long ptrace(enum __ptrace_request request, pid_tpid, void *addr, void *data); • This function tells the operating system to stop the program pid, return the current program counter (PC) to the calling function. • There are a range of different kinds of requests that can be made via the __ptrace_request interface. (you can look at them in the man page) • A debugger provides a nice interface to the user for all these functions

13. Common Debug operations • run • start execution of this process from the very beginning • break • set a breakpoint. A place in the code where you want the execution to stop and control to be handed back over to the debugger • reports an integer on completion. This is the name of this breakpoint • delete breakpoint-number • remove a breakpoint. no arguments means delete all breakpoints • disable breakpoint-number • turn a breakpoint off, but leave it in available • cont number • resume execution until next number of breakpoints have been hit. default is 1 • next • advance to the next line of the program and stop again

14. step • advance to the next instruction, entering functions if necessary and stop again • print • show the value of a variable in the current frame • [up|down] • move the debugger focus up and down the call stack • where • Show where the debugger is in the current total call stack • finish • execute to the end of this frame, then halt again • set • control your gdb environment • > set print static off

15. programs within programs • gdb is a nicer interface to the debugging process than writing tracing programs using ptrace • Other programs can provide a nicer interface than straight gdb • Our group regularly runs gdb from inside emacs • demonstration