Hunter Liu's Website

1. Week 1 Tuesday: Input/Output, Variables, and Errors

The following is a minimal program in C++ that prints the sentence “Hello world!” to the console:

1#include <iostream> 
2
3using namespace std; 
4
5int main() {
6    cout << "Hello world!" << endl; 
7
8    return 0; 
9}

The numbers to the left are the line numbers and are not part of the code; they give us references to describe the code. Removing any one of the (non-empty) lines of this program will cause your compiler to complain. Let’s talk about what each line of code does, in no particular order.

• Lines 5 and 9 bookend the main function. Everything between these two lines is run by the computer.
• Line 8 is a return statement. The main function needs to return an integer, and a return value of 0 indicates that nothing broke during the program. Return statements will come up in a few weeks, when we discuss functions.
• Line 1 tells the computer to use the iostream library. You must include this line if you want to use cin, cout, or endl.
• Line 3 tells the computer to use variables from the std namespace. For the purposes of this class, always include this line.
• Line 6 tells the computer to print out Hello world!, followed by a new line.

If we want to make our programs more interactive, we may request the user for input. The following snippet (part of a program) reads a user’s birth year, then computes their age at the end of 2023, and finally outputs this to the screen.

 1// prompt user for birth year 
 2cout << "Which year were you born?" << endl; 
 3
 4// read and store user's input 
 5int birth_year; 
 6cin >> birth_year; 
 7
 8// compute their age by subtracting from 2023 
 9int age = 2023 - birth_year; 
10
11// print result to screen 
12cout << "You will be " << age << " at the end of 2023." << endl; 

Here is a sample of how the code should run:

OUTPUT: Which year were you born? 
INPUT:  1947
OUTPUT: You will be 76 at the end of 2023.

A few remarks about this:

1. Comment your code liberally. Although this example is contrived and rather simple, we will later encounter far more complicated algorithms wherein the code is not self-explanatory. It may make sense in your head now, but you will find that months later, you will need comments to make sense of your code. Your colleagues also cannot read your mind.
2. Choose good variable names. We will discuss exceptions to this rule later, but it is imperative that the variable names give some clue to their purpose, particularly in more complex programs.
3. Notice the “extra” spaces on line 12. The program will output exactly every character you type. It’s common to type "You will be" and "at the end of 2023." without those additional spaces, but this would produce the output You will be76at the end of 2023. instead.

Finally, we should note that the user has complete freedom to input whatever they want:

OUTPUT: Which year were you born? 
INPUT:  Nineteen Eighty-four
OUTPUT: You will be 2023 at the end of 2023.

We may except them to input an integer, but our confused friend here entered a string, causing an unexpected age to be printed. This causes something called undefined behaviour — the output varies from computer to computer, and even from user to user, even if the exact same input is used. Handling unexpected input is beyond the scope of this lesson, but it highlights the next common source of error.

Finally, to tie everything off, let’s delineate between several types of errors you’ll likely encounter throughout this course.

• Build errors: errors that prevent the computer from understanding your code. These include things like syntactic errors, such as a missing semicolon, or using undefined variables, or forgetting an #include. An analogue in language would be having a grammatically nonsensical sentence or using words that don’t exist. (Babingus stemat mir yistamul plax./The dog water box it and monitor.)
• Runtime errors: errors that occur when the program can be compiled, yet crashes during runtime. We’ll encounter specific examples of these later in the course, but this includes things like accessing unallocated memory or your computer just using more memory than it has. An analogue in language would be saying a grammatically correct sentence comprised of real words, yet fails to produce a coherent meaning. (The blue eats solemnly bound tibula.)
• Logical errors: errors that occur when the program runs without breaking, yet still produces nonsensical output. We’ll see many more of these when we talk about control flow (if statements and loops). I can’t think of an analogue in language.

For this class, we’ll focus on identifying and correcting build errors by reading the error messages produced by the compiler. This is a critical skill that’s used in projects of every size.