Before You Code — C++ Pre-Course

Think of a variable as a labeled box. You put a value inside it — a number, a word, whatever — and you give the box a name so you can find it again later. "Put 5 into a box named score" is exactly what a line of code like int score = 5; means. The name is how you refer to the value later; the box is where the value actually lives while your program runs.

A box meant for whole numbers doesn't sensibly hold a word, and a box meant for text doesn't sensibly hold a decimal number. This is why programming languages — including C++ — have different types of boxes for different kinds of information:

C++ is unusually strict (compared to some languages) about knowing in advance exactly what KIND of box you're creating — this is a deliberate design choice that catches a whole category of mistakes before your program even runs, which you'll appreciate much more once you've been burned by the alternative.

Unlike a real sticky note you'd have to cross out and rewrite, a variable's value can simply be updated — put a new value in the same labeled box, replacing the old one. Your program might store a score of 0 at the start, then update that exact same box to 10, then 25, as the game progresses. The label (the name) stays the same; what's inside changes.

A decision in code follows one simple shape: check whether something is true, and if it is, do something specific. Optionally, you can also say what to do if it ISN'T true. That's genuinely the whole concept — everything else is just detail on top of "if this, then that, otherwise this other thing."

A condition a program checks always boils down to something that's either true or false — never "sort of" or "maybe." "Is the score greater than 100?" "Is the door open?" "Did the user type the correct password?" Each of these has exactly one honest answer at any given moment: yes or no. This yes/no nature is precisely what lets the computer make a clean, unambiguous decision.

Real decisions are often more layered than a single yes/no — "if it's raining AND I don't have a car, bring an umbrella AND wear boots. Otherwise, if it's just cold, wear a coat. Otherwise, wear whatever." This is still built from the same basic "if this, then that" idea — just multiple conditions checked in sequence, with the program following whichever path actually matches the real situation.

A loop lets you write a step (or group of steps) a single time, and tell the computer "now do this again and again" — either a specific number of times, or until some condition (from last lesson!) is no longer true. The computer handles the actual repetition; you only ever write the instruction once.

Both shapes exist in C++ (you'll meet them properly as for and while loops later in this course) — but conceptually, they're both just "repeat this step, either N times or until something changes."

The real power shows up when you combine last lesson's decisions WITH repetition: "Keep drawing cards until you have a total of 21 or more, but if you ever go over 21, stop and you lose." That single sentence already contains a loop (keep drawing) and a decision (checked every single repetition) working together — and this exact kind of combination is the backbone of almost every real program you'll ever write.

A function is a named, reusable group of instructions. You write the steps once, give them a name, and from then on, you can run that whole group just by using its name — anywhere in your program, as many times as you want — instead of retyping every step each time.

"Make coffee" is useful, but "make coffee, but with oat milk instead" is more flexible. A function can accept information when it's used — called parameters — that changes exactly how it behaves that specific time, without needing an entirely separate named routine for every possible variation.

A function can also hand a result back to whatever asked it to run — "what's 15% of this restaurant bill?" is a named routine that takes a number in and gives a specific answer back out, rather than just performing an action. This "takes something in, gives something back" pattern is one of the most common and useful shapes a function takes.

Functions are how real programs stay manageable as they grow. Instead of one enormous, tangled list of thousands of steps, a real program is broken into many small, clearly-named functions — each handling one specific job — that call each other in combination. This is also exactly why good naming matters: a function called calculateTax tells you what it does without needing to re-read every step inside it.

Unless a decision or a loop (from the last two lessons) says otherwise, a computer reads and runs your code exactly like you'd read a page of text: top to bottom, one instruction at a time, in the order it's written. It doesn't skip ahead, doesn't guess what comes next, and doesn't run two instructions at once by default.

This is the single most important mindset shift for a beginner. A computer doesn't guess what you probably meant, and it doesn't fill in gaps using common sense. If your instructions say to do something in an order that doesn't actually make sense — like using a variable's value before you've ever given it one — the computer will do exactly that broken thing, not politely correct your mistake for you.

When you talk to a person, "kind of," "sort of," and "probably" are perfectly normal. A computer has no tolerance for that kind of vagueness — an instruction either says exactly what to do, or it doesn't compile or run at all. This isn't the computer being unreasonably strict for no reason; it's simply what "no guessing, no assumptions" requires in practice. You'll get comfortable with this precision quickly — it becomes second nature within your first few real programs.

Broadly, programming languages fall into two camps for how they actually run:

C++ is compiled. This is the single biggest practical difference you'll notice coming in with no prior experience: you don't just "run" your C++ code directly. You compile it first, and THEN run the result.

The code you'll write is genuinely readable by a person (once you know the syntax) — words like if, while, and meaningful variable names. But a computer's processor doesn't actually run that text directly; it only runs extremely low-level binary instructions called machine code. The compiler is the program that bridges this gap: it reads your human-readable C++ source code and produces the machine code your specific computer can actually execute.

Every single time you change your code, you'll repeat the same three-step cycle: write (edit your source code), compile (translate it into a runnable program), run (actually execute it and see what happens). If the compiler finds a mistake in your code, it stops and shows you an error instead of producing a runnable program at all — you fix the mistake, and compile again. Lesson 12 covers exactly how to read those error messages without panicking.

This course recommends installing an IDE rather than a bare text editor, specifically because an IDE bundles helpful features (like catching simple mistakes as you type) that make the very beginning of your C++ journey noticeably less frustrating.

After installing, the most reliable way to confirm everything's actually working is to check your compiler's version from a terminal (Lesson 9 covers terminals properly, but here's a preview): open a terminal window and type g++ --version (or clang++ --version on macOS). If a version number prints back, your compiler is correctly installed and ready. If you instead see an error like "command not found," the installation didn't complete correctly, or the compiler isn't on your system's PATH — a very common first hurdle, and not a sign you did anything unusually wrong.

Toolchain installation is, honestly, one of the most common places beginners get stuck — often before they've written a single line of actual code. If something doesn't work on the first try, that's completely normal and not a reflection of your ability to learn C++. Searching your exact error message plus your operating system is a genuinely effective troubleshooting strategy, and one you'll keep using throughout your entire programming career, not just here.

Everything you've done on a computer so far — opening apps, moving files — has a typed equivalent. A terminal (also called a command line or console) is a program where, instead of clicking, you type the name of what you want to do. It's not a more "advanced" computer underneath — it's the same computer, just a different way of telling it what to do, and one that happens to be how you'll compile and run C++ programs throughout this entire course.

Most IDEs (including Visual Studio and CLion) also have a terminal built directly into the application window, so you may not even need to open a separate one once your editor is set up.

• Press Tab to auto-complete. Start typing a file or folder name and press Tab — most terminals will finish it for you, saving typing and avoiding typos.
• Press the Up arrow to reuse a previous command instead of retyping it.
• Capitalization and exact spelling matter. A terminal won't guess what you meant the way a search engine might.

A C++ program starts as a plain text file — genuinely no different in kind from a .txt file, just saved with a .cpp extension instead, which tells your compiler and editor "this text is C++ code." You'll create, save, rename, and organize these files exactly like any other file you've ever worked with — the only new part is what you'll type inside them.

Just like you might keep a folder for photos and a separate one for documents, you'll want a dedicated folder for your C++ projects — commonly something like a folder named cpp-projects inside your Documents. Inside that, most people create a separate subfolder for each individual program or project, keeping related files together and separate from unrelated ones.

A path is just the full set of directions to a specific file or folder, written out — the same information you'd give someone verbally ("it's in Documents, then cpp-projects, then hello-world"), just written in a compact, standard format.

Both Windows and macOS hide file extensions (the .cpp, .txt part) by default in their file browsers — genuinely useful for casual computer use, but actively unhelpful once you're writing code, since you'll frequently need to see and confirm exact file extensions. It's worth turning this setting on now: search "show file extensions" plus your operating system for quick, current instructions.

Remember the "labeled box" from Lesson 2? In C++, creating one looks like this:

int score = 5;
double price = 19.99;
std::string name = "Alex";

Read the first line as: "Create a whole-number box named score, and put 5 in it." int is the TYPE of box (whole numbers), score is the label, and = 5 is what goes inside. The semicolon simply marks "this instruction is finished" — C++ uses it to know where one instruction ends and the next begins, since (unlike English) it doesn't rely on line breaks alone.

if (score > 100) {
    // do this if the condition is true
} else {
    // do this otherwise
}

This is precisely "if it's raining, bring an umbrella, otherwise don't" from Lesson 3 — if (condition) introduces the check, the curly braces { } group together everything that should happen for that branch, and else covers the "otherwise" case.

for (int i = 0; i < 20; i++) {
    // do this 20 times
}

This is "do 20 push-ups" from Lesson 4. You'll learn exactly what each of the three parts inside the parentheses means in Module 2 — for now, just recognize the shape: a loop repeats whatever's inside its curly braces.

int calculateTax(double price) {
    return price * 0.08;
}

This is "make coffee" from Lesson 5 — a named routine (calculateTax) that takes information in (price) and gives a result back (return). You'll call this named routine elsewhere in your program just by writing calculateTax(19.99).

Using your project folder from Lesson 10, create a new file named exactly main.cpp inside a fresh folder (something like cpp-projects/hello-world/). Open it in your editor or IDE from Lesson 8, and type the following exactly as shown:

#include <iostream>

int main() {
    std::cout << "Hello, world!" << std::endl;
    return 0;
}

Open a terminal (Lesson 9), navigate to your project folder using cd, and run:

g++ main.cpp -o hello

Read this as: "compiler, translate main.cpp, and name the resulting program hello." If nothing prints back and you're returned to a normal prompt, it worked — no news is good news here. A new file (on Mac/Linux, named hello; on Windows, hello.exe) now exists in that same folder.

./hello

(On Windows, just type hello without the ./.) You should see Hello, world! printed to your screen. If you see that — genuinely, congratulations. You just wrote, compiled, and ran a real C++ program, from nothing, on your own machine.

A C++ compiler error can look like a dense wall of unfamiliar text. But underneath the intimidating formatting, it's always trying to tell you exactly three things: which file the problem is in, which line it's on, and what specifically the compiler couldn't understand. Once you know to look for those three pieces, the wall of text becomes much more approachable.

Suppose you accidentally forgot a semicolon:

int score = 5
int total = 10;

The compiler might respond with something like:

main.cpp:2:1: error: expected ';' after top level declarator
    int total = 10;
    ^
    ;

1. Find the file and line number — go directly there in your editor.
2. Read the error description slowly — it's often more literally accurate than it first feels.
3. Check the line above, too — per the callout above.
4. If you're stuck, search the exact error text — copy the core error message (not your specific variable names) into a search engine. This is a completely normal, universally-used technique, not a sign of inexperience.

Plus the mechanical skills that make all four of those actually usable: what compiling means, a working C++ toolchain installed on your own machine, enough terminal command to navigate confidently, understanding files/folders/paths, and — critically — the ability to read a compiler error without panicking.

You've already done the two things that stop most people before they really start: you got a real compiler working on your own computer, and you compiled and ran a real program successfully. Everything from here is deepening skills you've already started using — not starting from zero again.

Phase 1 (C++ Fundamentals) picks up exactly where this Pre-Course leaves off — the same four Big Ideas, now explored in real depth with real C++ syntax: every data type, every operator, proper input with cin, and enough practice to make writing a variable declaration feel automatic instead of something you have to think through step by step.