Hunter Liu's Website

1. Week 1 Tuesday: Getting Started

Welcome to PIC 10A! First thing’s first, make sure you have an integrated development environment (IDE) set up. This is a program that lets you edit, compile, and run code, basically everything you’ll need to do in this class, all from one place. If you’re on Windows, please install Microsoft Visual Studio Community 2022 (you’ll have to scroll down a bit). If you’re on Mac, please install XCode. If you’re using another operating system like ChromeOS, you may use an online IDE of your choosing, e.g. OnlineGDB.

When installing Visual Studio, make sure you’re also installing the “Desktop Development with C++” thingie under “workloads”. I don’t have access to a Mac, so hopefully XCode comes with C++ by default.

In both Visual Studio and XCode, you’ll need to create a new project every time you want to write a new program. One project per program! Otherwise things will stop working.

On Visual Studio, follow these instructions on the PIC website. Select New Project > Console App, then choose a project name and location.

On XCode, create a new project by selecting File > New > Project..., then choosing “MacOS” and “Console Application” on the popup menu. Choose a location to store the file, and make sure the language is C++! The default language is sometimes set to Swift.

There are two things I’d like to discuss before we get in the weeds with actually coding stuff up: first, we’ll use words like “compile” and “run” to describe the process of converting your code into a working program. What exactly do these words mean? Second, almost surely you’ll be making various mistakes when you do begin writing code. What are the different kinds of mistakes that are made, and why should we care about them?

You’ll need to know the latter for this course, but I think it’s equally important to have a bit of context for what’s happening when you press that glowing green play button.

The Compilation Pipeline

The very first step in creating a computer program (for whatever purpose) is writing the code itself. These are saved in .cpp files, and you may have seen the following program in the first day of lecture:

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

This is saved in a file, e.g. hello_world.cpp, somewhere in your project folder. However, the computer doesn’t just run the code as-is, and in fact it’s kind of mysterious how the computer goes from this code to performing a concrete action. What the heck do those first two lines of code do, for instance?

There are three steps that actually happen:

1. Compiling — another program called a compiler looks at hello_world.cpp and translates it into an incomplete set of instructions for your computer to run. Parts of the instructions are in this mysterious iostream that we “included” at the top, so a bit of your program is actually hiding wherever this iostream actually is.
2. Linking — another program called a linker stitches together the distinct pieces of your instructions into a single functional program. It brings together both the code you wrote and the code hiding in iostream.
3. Executing — this is the step where the instructions from the prior step are actually performed by the computer, resulting in a “Hello World!” popping up in a console.

Steps 1 and 2 may be referred to together as “building”, though is sometimes conflated with “compiling” code. Of course, once you’ve built the code once, you can run it again and again without having to go through those first two steps again and again.

This is a sort of stripped-down version of what happens, and this won’t show up on exams. However, it’s important to know in general — when working on your homework, you may want to code your solutions in stages, adding code a few lines at a time until you get something that works. When you just “Run” your code, the first two steps are skipped, and your program will not actually change to reflect your new code. You’ll need to “Build and Run” your code. Be very careful with this distinction!

Bugs and Errors

Before we start coding, we should learn everything that can possibly go wrong when coding. You should think of writing code as communicating with the computer: you’re handing it a list of instructions to perform. This usually proceeds in four vague steps:

1. You think really hard and dream about what you want the computer to do.
2. You write the actual code that you thought really hard about.
3. The code is built into a program.
4. The program is run.

At every step of the way, something can go wrong. The most common error occurs in step 3, when the compiler cannot understand or interpret the code you wrote. (When we deal with multi-file projects, the linker might freak out too.) These are “compilation errors” or “syntax errors”.

When your code is able to be built into a functional program, there’s still room for error, and this will usually manifest in either your program falling apart and crashing or your program working just fine but still not doing what you expect it to do.

In the former case, when the program straight up crashes, this is called a “runtime error”. These are rather rare early on in the course, as it’s hard to guide your computer into self-destructive behaviour. However, this can occur when you ask the computer to do something it’s not allowed to do or try to do something outside the physical constraints of your computer (i.e. running out of memory).

In the latter case, this is indicative of something wrong with the “thinking and writing” stages. Most often, your code is functional but doesn’t reflect the intentions you had in the first step. Sometimes, however, there’s something inherently wrong with the actions or decision-making you’re telling the computer to make. These are called “logical errors”.

The three types of errors all manifest differently and need to be debugged differently. Compilation errors are accompanied by very verbose error messages from the compiler itself. Though daunting to read as humans, they often (but not always) tell you exactly what you need to change in your code to fix the error. Runtime errors in C++ are (thankfully) now often accompanied with detailed error messages too, indicating what exactly happened immediately before the crash.

Logical errors, however, are a lot more subtle. To fix these errors, you need to carefully walk through the code your wrote and find out exactly what it’s doing. You may also realise that your code is structurally unsound, prompting you to start over from the beginning.

Thus, throughout this course, we’ll not only need to learn how to write correct code, but we’ll also need to develop the skills necessary to fix the code when it inevitably goes wrong. The code-writing skills will be developed during lecture, and in discussions, we’ll see a bit of code-writing too. But we’ll also see:

• how to effectively plan code, particularly so we can avoid logical errors,
• how to predict what code will do, so we can identify logical errors when our planning fails,
• and how to identify common runtime and syntax errors, alongside reading the error messages.

The best way to learn all these skills, by the way, is not by sitting in a classroom and watching someone else describe what’s happening. Despite our best efforts, we’re teaching you how to code in a very sterile and predetermined environment. The best way to learn is to think of a program you want to make (within reason), then go and make it. You’ll make mistakes, but you’ll learn so much more from those mistakes than from watching me pretend to make mistakes or not make any at all.