|
Quick Summary A syntax error is an error that occurs when you write a statement that is not valid according to the grammar of the C++ language. The compiler will catch these. A semantic error occurs when a statement is syntactically valid, but does not do what the programmer intended. The process of finding . . . → Read More: 3.x — Chapter 3 summary and quiz When you make a semantic error, that error may or may not be immediately noticeable when you run your program. An issue may lurk undetected in your code for a long time before newly introduced code or changed circumstances cause it to manifest as a program malfunction. The longer an error sits in the code . . . → Read More: 3.10 — Finding issues before they become problems Modern debuggers contain one more debugging information window that can be very useful in debugging your program, and that is the call stack window. When your program calls a function, you already know that it bookmarks the current location, makes the function call, and then returns. How does it know where to return to? The . . . → Read More: 3.9 — Using an integrated debugger: The call stack While stepping (covered in lesson 3.6 — Using an integrated debugger: Stepping) is useful for examining each individual line of your code in isolation, in a large program, it can take a long time to step through your code to even get to the point where you want to examine in more detail. Fortunately, modern . . . → Read More: 3.7 — Using an integrated debugger: Running and breakpoints In the previous lesson (3.4 — Basic debugging tactics), we started exploring how to manually debug problems. In that lesson, we offered some criticisms of using statements to print debug text: Debug statements clutter your code. Debug statements clutter the output of your program. Debug statements require modification of your code to both add and . . . → Read More: 3.5 — More debugging tactics In the previous lesson, we explored a strategy for finding issues by running our programs and using guesswork to hone in on where the problem is. In this lesson, we’ll explore some basic tactics for actually making those guesses and collecting information to help find issues. Debugging tactic #1: Commenting out your code Let’s . . . → Read More: 3.4 — Basic debugging tactics When debugging a program, in most cases the vast majority of your time will be spent trying finding where the error actually is. Once the issue is found, the remaining steps (fixing the issue and validating that the issue was fixed) are often trivial in comparison. In this lesson, we’ll start exploring how to find . . . → Read More: 3.3 — A strategy for debugging Let’s say you’ve written a program, and it’s not working correctly — the code all compiles fine, but when you run it, you’re getting an incorrect result. You must have a semantic error somewhere. How can you find it? If you’ve been following best practices by writing a little bit of code and then testing . . . → Read More: 3.2 — The debugging process Software errors are prevalent. It’s easy to make them, and it’s hard to find them. In this chapter, we’ll explore topics related to the finding and removal of bugs within our C++ programs, including learning how to use the integrated debugger that is part of our IDE. Although debugging tools and techniques aren’t part of . . . → Read More: 3.1 — Syntax and semantic errors Quick Summary A function is a reusable sequence of statements designed to do a particular job. Functions you write yourself are called user-defined functions. A function call is an expression that tells the CPU to execute a function. The function initiating the function call is the caller, and the function being called is the . . . → Read More: 2.x — Chapter 2 summary and quiz |
