|
Consider a case where you’re going to go to the market, and your significant other tells you, “if they have strawberries on sale, pick some up”. This is a conditional statement, meaning that you’ll execute some action (“pick some up”) only if the condition (“they have strawberries on sale”) is true. Such conditions are common . . . → Read More: 4.10 — Introduction to if statements Before we talk about our next subject, we’re going to sidebar into the topic of scientific notation. Scientific notation is a useful shorthand for writing lengthy numbers in a concise manner. And although scientific notation may seem foreign at first, understanding scientific notation will help you understand how floating point numbers work, and more importantly, . . . → Read More: 4.7 — Introduction to scientific notation Unsigned integers In the previous lesson (4.4 — Signed integers), we covered signed integers, which are a set of types that can hold positive and negative whole numbers, including 0. C++ also supports unsigned integers. Unsigned integers are integers that can only hold non-negative whole numbers. Defining unsigned integers To . . . → Read More: 4.5 — Unsigned integers, and why to avoid them 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 home 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 to find 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 . . . → Read More: 3.3 — A strategy for debugging |
