Chapter 1 — The Sport of Programming and the Memory It Runs On

“You don’t rise to the level of your goals. You fall to the level of your training.”

“…always being prepared to make a defense to anyone who asks you for a reason for the hope that is in you; yet do it with gentleness and respect.” — 1 Peter 3:15

This week merges Coding 1 chapters 1 and 2. If you have the sixteen-week book beside you, everything in “The Sport of Programming” and “Memory: Variables and Types” is here — resequenced into one week, because the two halves are the same idea seen from two sides.

Your Week at a Glance

Twelve honest hours — hands on keys, not the book open while a video plays in another tab. Four sessions of about three hours is the shape that works; two sessions of six is not, because your hands need sleep between reps as much as your brain does.

Be honest about the arithmetic: Session 1 will run long the first time, because setting up a browser IDE and learning to read compiler errors are both once-in-a-lifetime costs. Steal the time back by starting the project’s card half at the end of Session 3. Do not steal it from the reps. The reps are the course.

Why This Matters

Watch a professional musician for sixty seconds. Their fingers move without their eyes following. They aren’t thinking “index finger to the third fret” — that conversation ended years ago. The instrument is an extension of what they want to say.

That’s where we’re going: by the end of these eight weeks you’ll sit down with a problem in your head and just type the solution, because the skill lives in your hands. The instrument doesn’t matter. The skill does.

And the skill — articulating a careful idea clearly enough that something else can follow it — is the same one you need in the parts of life where someone asks, “wait, why do you actually believe that?” The compiler is the most patient and least sympathetic interlocutor you will ever meet. It gives no partial credit for almost clear thinking.

This week you make a program talk, listen, and remember. That’s the whole first pillar.

1.1 — The Confession

(A note for the Lutheran ear: this book uses confession in the sport sense — “let me tell you what’s hard” — not the catechetical sense.)

Most intro programming books read like math textbooks. They walk you through theorems and expect you to understand them, and the implicit promise is “if you understand this, you can do it.”

That promise is a lie. You can read every page of every programming book ever written and still freeze the first time you face a blank file. Only one thing closes the reading-to-doing gap:

Reps.

Reps are why a basketball player sinks a free throw with their eyes half-closed and why a touch-typist doesn’t look down. Reps build what engineers call automaticity — the point where a skill stops requiring conscious thought.

This book bets you’ll do them. And it bets on something else, which is the reason this edition exists: nobody is going to check. No hand to raise, nobody glancing over at your screen, no room where someone notices you’ve fallen behind. So every rep here ships with the exact output it should produce, and every chapter ends with a checkpoint you can grade yourself against honestly. The book can’t make you train. It can make sure that when you train, you know whether you got it right.

Coach’s Note — Most students finishing an intro course can talk about loops and conditionals. A small minority can open a blank file and write a working program. The difference is reps. In an eight-week course that difference surfaces twice as fast, because there’s half as much calendar to hide in.

1.2 — What You’re Actually Learning

Second confession: this course is not really about C++, or Java, or any language. It’s about one learnable, transferable skill that languages happen to be the medium for:

The skill is articulating a solution clearly enough that a machine can follow it.

Humans are fantastic problem solvers — you solve thousands of problems a day without noticing, from getting dressed to apologizing after a fight. What we don’t usually do is articulate the solution out loud, in detail, in the right order, with no ambiguity. That’s the skill.

A computer is the ultimate no-ambiguity audience. It does exactly what you say. Not what you meant. What you said.

And since this course is what it is, worth saying once: articulating a careful idea clearly is the same move 1 Peter 3:15 asks for when it tells Christians to be prepared “to make a defense to anyone who asks you for a reason for the hope that is in you.” A reason isn’t a feeling or a slogan. It’s a clean chain of thought you can hand to another person — or to a machine — and have them follow. Same skill, different audience.

Coach’s Note — This reframe means you already have most of the skill. The hard part is precision, not intelligence. If you can plan a road trip or follow a recipe, you have the raw materials.

1.3 — The Three Pillars

Almost every program is the same three moves in different combinations.

Pillar 1: Memory. Humans remember things — where we parked, whether the stove is on, the books of the New Testament. Computers use a variable: a named box holding a value.

score = 0
name = "Maya"
is_logged_in = true

This chapter is almost entirely this pillar, which is why its second half exists.

Pillar 2: Asking questions. Humans constantly ask “is this true?” and act on the answer. Is the milk expired? Then throw it out, otherwise pour it in the coffee. Is this claim about Jesus’ resurrection consistent with the earliest sources we have? Then we have something to deal with, otherwise we don’t. Programs do this with conditionals — usually if. That’s Chapter 2.

Pillar 3: Repetition. Brushing every tooth. Washing every dish. Praying the same prayer every morning until the words mean something different than they did the first morning. Computers are spectacular at this; the tools are loops and functions, in Chapters 2 and 3.

Memory, questions, repetition. Every nontrivial program ever written is these three combined — which is also why this course can switch you to Java in Week 7 without ceremony. All three exist in both languages.

Coach’s Note — When a later concept feels weird — pointers, classes, inheritance, polymorphism — ask: “is this a memory thing, a questions thing, or a repetition thing?” Almost always it’s one of the three in a fancier outfit. Pointers are memory. Classes are memory with rules attached. Inheritance is memory shared between two boxes.

1.4 — Why C++ First, Then Java

Six weeks of C++, then Java in Week 7. The order isn’t arbitrary.

C++ is a stick shift. Java is an automatic. Both cars have gears; the difference is who shifts them. Driving stick, you work the clutch and pick the gear, so you learn what each gear is for. It’s harder — but afterward you understand cars at a level an automatic-only driver doesn’t.

C++ makes you work the clutch: you manage memory by hand, you declare what type every box is, you free what you allocate. Java does much of that for you. Going from stick to automatic is easy; the other direction is brutal. So we start with stick. By Week 7 Java will feel like a gift — wait, the language manages memory for me? — and you’ll also understand what that convenience costs, because you felt the alternative.

A word about vocation while we’re here. Lutherans have a word for the work you’re about to do: vocation — any honest calling through which a person serves the people around them. The baker bakes bread; the bread feeds the neighbor. The work itself is the means. We won’t make a weekly production of this, but once is worth it: learning to write clearly and carefully is a small vocation. The neighbor next to you needs code that doesn’t crash; the neighbor twenty years from now — possibly you — needs code they can still read. Do honest work in the room you’re in.

1.5 — Your Toolkit and the Compile–Run Loop

You need one thing: a browser and a free OnlineGDB account. No installs, no purchases, no institutional logins. It runs C++ and Java, which is the entire span of this book. Appendix A covers setup in about five minutes, including where the compiler-flags box lives — put -Wall -Wextra in it, because every project here is graded on compiling with those flags and no warnings.

Why no local compiler? Because the point is to write code, not to debug PATH variables. If you already have a working local toolchain, use it; you’re then responsible for keeping it working.

Here’s the loop you’ll run several hundred times:

1. Type or edit the source file.
2. Compile it.
3. If the compiler complains, read the FIRST error, fix that one thing, go to 2.
4. Run it.
5. Compare what it printed to what you expected.
6. If they differ, change one thing and go to 2.

On OnlineGDB, steps 2 and 4 are the single Run button — it compiles, and if that succeeds, it runs. Locally the two steps are separate:

g++ -std=c++17 -Wall -Wextra hello.cpp -o hello
./hello

Two habits to build now. Read the first error, not the last — one missing semicolon can produce nine errors, and eight are the compiler flailing after the first confused it. Change one thing between compiles — change four and it starts working, and you don’t know which one fixed it.

Coach’s Note — Do not spend two hours perfecting your environment before writing your first program. Get the minimum setup — for OnlineGDB that’s literally “sign in” — then let the tools earn their place. Time spent tuning tools is time not spent on reps.

1.6 — Your First Program, Character by Character

Create hello.cpp. Type this — do not paste it. Every character. This is your first rep.

#include <iostream>
using namespace std;

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

Run it. You should see exactly:

Hello, world.

Six lines of code, one line of output; the file is code/hello.cpp. Now walk through it. There is no magic here, and every symbol earns its keep.

#include <iostream> — a preprocessor directive. It says “before compiling this file, paste in the contents of iostream,” the standard library’s toolbox for talking to the screen and keyboard. cout lives there. Without this line, cout does not exist.

using namespace std; — C++ sorts names into namespaces so two libraries can both define a list without colliding. The standard library lives in std; without this line you’d write std::cout every time. Professional code often considers it bad form (it dumps a whole namespace into your file), but it keeps a teaching book clean, so we use it throughout.

int main() { — the most important line in any C++ program. When you run a compiled program, the operating system looks for a function named main, and that’s where execution starts. Every C++ program has exactly one.

• int — the return type: this function hands back an integer.
• main — the name, special because the OS knows to start here.
• () — the parameter list, empty, so main takes no arguments.
• { — opens the body; the matching } closes it.

cout << "Hello, world." << endl; — where the work happens.

• cout is “console out,” an object wired to the screen.
• << is the stream insertion operator — read it as “send this to.” The arrow points the way data flows.
• "Hello, world." is a string literal; double quotes mark it as text rather than code, and the compiler passes what’s inside through unchanged.
• << endl sends end-of-line: move the cursor to the next row (and flush the output buffer).
• ; is the statement terminator. Forget one and the compiler tells you loudly — §1.11 shows you exactly how loudly.

return 0; — ends main and reports “finished successfully.” Non-zero, like return 1;, conventionally means something went wrong. Zero is good, non-zero is bad; backwards from scoring, but universal.

} — closes main. The program ends.

Notice we skipped nothing. When something later confuses you, slow down and ask “what is each symbol for?” Almost always the confusion traces to a symbol you let slide.

One convention for the rest of the chapter, so you’re never guessing what you’re looking at. Complete programs — like the one you just typed — are always shown whole, #include lines and all, and you can paste one into an empty OnlineGDB tab and press Run. A block that starts indented, with no #include lines, is an excerpt: the interesting middle of a longer file, with the includes and int main() { ... } wrapped around it. The sentence just above such a block names the file in this chapter’s code/ folder that holds the whole thing. And a short flush-left block with no main is simply the line or two under discussion — read it, don’t try to compile it by itself.

1.7 — Comments: Notes for the Only Person Who’ll Read This

A comment is text the compiler ignores completely. Two forms:

// Single-line comment. Everything after the // is ignored.

/*
   Block comment.
   Runs until the closing marker, however many lines that takes.
*/

Comments cost nothing at runtime — they don’t exist in the compiled program. They exist for readers, and in this course the reader is one of two people: your grader, or you three weeks from now. Neither will have you sitting beside them explaining.

Three rules worth a career:

1. Comment why, not what. The code already says what.

score += 5;    // ❌ adds 5 to score  (we can see that)
score += 5;    // ✅ bonus for finishing the week's reps

2. A comment that lies is worse than no comment. Change the code, change the comment.

3. Head every file with what it is. Every file in this chapter’s code/ folder starts with a few lines saying what it demonstrates and how to build it. Copy that habit — every project in this course also requires a reflection comment block at the top of your main source file.

There’s a fourth use, and this week it’s the important one: commenting out a line to isolate a bug. Put // in front and it stops existing. Recompile. Did the problem vanish? Then that line was the problem. It’s the cheapest debugging tool in the language and it’s available at 2 a.m. when nothing else is.

1.8 — Shaping the Output

cout prints exactly what you send and nothing more — no spaces between items, no line breaks. If your output looks jammed together, you didn’t ask for the gaps. Three tools:

• endl — ends the line (and flushes the buffer).
• "\n" — the newline escape sequence, also ends the line. Inside a string, a backslash means “the next character is special.” Either is fine in this book.
• "\t" — the tab escape, jumping to the next tab stop (every eight columns in most consoles).

Two more escapes: \" puts a literal double-quote inside a string, and \\ a literal backslash.

Here’s output shaped on purpose — the layout vocabulary Project 1’s card half is built from. This is the middle of code/card_layout_demo.cpp:

    string name = "Marcus";
    string from = "Concordia";

    cout << "+-----------------------------------+" << endl;
    cout << "|           APOLOGIST CARD          |" << endl;
    cout << "+-----------------------------------+" << endl;
    cout << "  Name:  " << name << endl;
    cout << "  From:  " << from << endl;
    cout << "  Week:  1 of 8" << endl;
    cout << "  Goal:  Be coding in any language\n";
    cout << "         by Week 8." << endl;
    cout << "+-----------------------------------+" << endl;

    cout << endl;
    cout << "Reps:\t12\tSkipped:\t0" << endl;
    cout << "Bugs:\t3\tFixed:\t\t3" << endl;

Its actual output:

+-----------------------------------+
|           APOLOGIST CARD          |
+-----------------------------------+
  Name:  Marcus
  From:  Concordia
  Week:  1 of 8
  Goal:  Be coding in any language
         by Week 8.
+-----------------------------------+

Reps:	12	Skipped:	0
Bugs:	3	Fixed:		3

Look at the last two lines and notice what tabs really do. Skipped: is longer than Fixed:, so after Fixed: one tab lands short and a second was needed to line the numbers up. That’s the whole problem with \t — it aligns to fixed stops, not to your intentions. §1.18 gives you setw, which aligns to a width you choose.

1.9 — Making It Talk Back

A program that only prints is a one-way conversation. Add input — this is code/hello_with_input.cpp, whole:

#include <iostream>
#include <string>
using namespace std;

int main() {
    string name;

    cout << "What is your name? ";
    cin >> name;

    cout << "Welcome to the gym, " << name << "." << endl;
    return 0;
}

Run it and type Marcus (the text after the prompt is what you typed):

What is your name? Marcus
Welcome to the gym, Marcus.

New pieces:

• #include <string> — the toolbox for the string type. Include it whenever you use string. (On most compilers, OnlineGDB’s included, <iostream> happens to drag <string> in behind it, so omitting it often compiles anyway. Don’t rely on an accident.)
• string name; — your first variable: a named container for text, currently empty.
• cin — “console in,” the opposite of cout.
• >> — the stream extraction operator, pulling data from cin into the variable on the right.

Read it out loud: “Send ‘What is your name?’ to the console. Read from the console into name. Send ‘Welcome to the gym,’ name, ’.’ to the console.” The arrows point the direction the data flows. C++ has plenty of ugly syntax; the I/O is not it.

That one variable is your first taste of Pillar 1: Memory. You stored a thing; you used it later.

One behavior to know now, because it will bite you: cin >> stops at the first whitespace. Type Marcus Aurelius:

What is your name? Marcus Aurelius
Welcome to the gym, Marcus.

Aurelius isn’t gone — it’s sitting in the input buffer waiting for the next cin >>, which will look to you like an input that got skipped.

1.10 — Reading a Whole Line: getline

When you want everything the user typed, spaces and all:

string manuscript;
getline(cin, manuscript);

getline(cin, some_string) reads to the end of the line and stores the whole thing. It’s the right tool for names, titles, addresses — anything a human might type with a space in it.

One wrinkle, and it’s among the most common beginner bugs in C++: if you read a number with cin >> and then call getline, the getline appears to be skipped and comes back empty. cin >> copies_read grabs the digits but leaves the newline you pressed sitting in the buffer; getline then reads from there to the end of the line — nothing at all.

The fix is one line:

cin >> copies_read;
cin.ignore();            // throw away the leftover newline
getline(cin, manuscript);

cin.ignore() discards exactly one character from the input buffer. You need it only at the boundary between a >> read and a getline. The whole thing works in code/getline_demo.cpp, whose middle is this:

    int copies_read = 0;
    string manuscript;
    string found_at;

    cout << "How many manuscripts have you read about? ";
    cin >> copies_read;
    cin.ignore();   // eat the newline still sitting in the input buffer

    cout << "Manuscript name (spaces are fine): ";
    getline(cin, manuscript);

    cout << "Where was it found? ";
    getline(cin, found_at);

Type 3, then Codex Sinaiticus, then Saint Catherine's Monastery, Sinai — sample input chosen because the third answer has spaces and a comma in it, which is the whole point — and the session looks like this:

How many manuscripts have you read about? 3
Manuscript name (spaces are fine): Codex Sinaiticus
Where was it found? Saint Catherine's Monastery, Sinai
---
Read about:  3
Manuscript:  Codex Sinaiticus
Found at:    Saint Catherine's Monastery, Sinai

Now delete the cin.ignore(); line and run it again. The Manuscript: row comes back blank and everything shifts by one. Do that experiment: thirty seconds of deliberate breakage buys an hour of not being confused later.

1.11 — Reading Your First Compiler Errors

Programs that work aren’t interesting; programs that break in a specific way teach the most. So break hello.cpp on purpose, five ways, and read what comes back. The text below is real GNU g++ output — the same compiler family OnlineGDB runs — captured from exactly these broken files. Where a message runs long, only the lines that carry the meaning are reproduced.

Break 1: delete the semicolon after endl.

hello.cpp: In function 'int main()':
hello.cpp:5:36: error: expected ';' before 'return'
    5 |     cout << "Hello, world." << endl
      |                                    ^
      |                                    ;
    6 |     return 0;
      |     ~~~~~~

Read it slowly, because every compiler error has this shape: file and position (hello.cpp:5:36 = line 5, column 36); severity and message (error: stops compilation, warning: compiles anyway but smells); the source line quoted back with a caret; and frequently the fix, printed right there — here g++ literally shows the ; it wants. Note that it blames line 5 but noticed on line 6. A missing semicolon is always reported at that boundary, so when an error names two lines, look at the first.

Break 2: delete #include <iostream>.

hello.cpp:4:5: error: 'cout' was not declared in this scope
hello.cpp:1:1: note: 'std::cout' is defined in header '<iostream>'; this is probably fixable by adding '#include <iostream>'

“Was not declared in this scope” is the most common error message in beginner C++ and always means the same thing: you used a name the compiler has never heard of. Misspelled, missing include, or used where it doesn’t exist. Read the note: — g++ diagnosed it for you.

Break 3: delete using namespace std;, keep the include. Now the message reads error: 'cout' was not declared in this scope; did you mean 'std::cout'? — same message, different tail. That tail is the giveaway: the name exists, but in a namespace you didn’t open.

Break 4: change int main() to int Main().

undefined reference to `main'
collect2: error: ld returned 1 exit status

Those two lines are the message; the text wrapped around them — a path to ld, an object-file name, a hex offset — varies from machine to machine and is noise. (On a Mac the same failure is phrased Undefined symbols ... "_main", which is the identical complaint in a different accent.)

This looks alien because it comes from a different program: your code compiled fine, since Main is a legal name. The linker, which runs after the compiler to assemble the executable, went looking for main and found none. When an error mentions ld, collect2, or “undefined reference,” you’re past the compiler. C++ is case-sensitive.

Break 5: delete the closing quote on "Hello, world.". You get error: missing terminating " character, followed by error: expected primary-expression before 'return' — nonsense, an aftershock. Fix the first error and recompile. Never try to fix them all.

Coach’s Note — Do these five breaks by hand right now, in your own file. You’re not memorizing messages; you’re learning that messages are readable, which is a different and far more durable skill. Students who never break anything on purpose spend Week 3 terrified of red text.

1.12 — The Bridge: One Week, Two Halves

Stop here, because this is the seam of the chapter and it deserves an argument rather than a transition sentence.

The sixteen-week book teaches everything above in Week 1 and everything below in Week 2. That split is a scheduling artifact, not a truth about programming. Look at what you already had to do to write the ten working lines of §1.9:

string name;
cin >> name;

To read one word from a human being, you had to decide before they typed anything what kind of thing they’d type — and reserve a box shaped like it. Choose string and Marcus fits. Choose int and it doesn’t, and the program fails in a way we’ll look at in §1.22. Input doesn’t land in the program; it lands in a variable. Output doesn’t come from nowhere; it comes from a variable. cout and cin are just the doors. Memory is the room.

That’s why this chapter’s title has two halves joined by “and.” A program that echoes what you typed is a parrot. The moment you want it to do something with what it heard — add it, compare it, round it, format it to two decimals — you must know exactly what kind of thing it heard, because C++ will not guess.

Memory, formally

A variable is a name attached to a chunk of memory that holds a value. That’s the whole concept. When you write int score = 0;, three things happen in order:

1. The compiler reserves a chunk of memory big enough for an integer (typically 4 bytes).
2. It files that chunk under the name score, so your code can use the name instead of a raw address.
3. It writes 0 into the chunk.

From then on, wherever you write score, the machine looks up where score lives and reads or writes there. The name is for you; the computer keeps a names-to-addresses table purely for bookkeeping.

Coach’s Note — Whenever a later concept confuses you, come back to that sentence. Pointers are names attached to chunks holding the addresses of other chunks. Structs are names attached to chunks made of several smaller chunks. Classes are structs with rules attached. It’s variables all the way down.

1.13 — The Five Types You Need This Week

C++ has dozens of types. These five do ninety percent of the work and are all Project 1 needs.

int — whole numbers. int year = 2026; Positive, negative, or zero; no fractional part; roughly ±2 billion on a modern machine. The critical thing: divide two ints and you get an int. 7 / 2 is 3, not 3.5, and the .5 is thrown away rather than rounded. §1.16 is entirely about this.

double — numbers with a decimal point. double temperature = 98.6; The name comes from “double-precision floating-point,” a historical artifact you can ignore. Scientific notation works too: read 1.1056e-52 as 1.1056 × 10⁻⁵², the digits times ten to that exponent — a compact way to write extreme numbers, and the form C++ prints them back in. The critical thing: a double is almost but not exactly accurate, representing 0.1 only approximately the way a decimal only approximates 1/3. For everyday math this rarely matters; for comparing two doubles with == it always does, which is why Chapter 2 tells you never to do that.

bool — true or false. bool program_complete = false; Exactly two values, named for the mathematician George Boole.

char — one character. char category = 'G'; Note the single quotes: 'A', not "A". Single quotes mean one char, double quotes mean a string. Real difference, not style — 'A' is one byte, "A" is two (the letter plus an invisible end-of-string marker) — and mixing them is a compiler error you’ll meet in §1.22.

string — text. string verse = "1 Peter 3:15"; Any length, double quotes, #include <string>. Technically it’s a standard-library class rather than a primitive — a distinction that matters in Chapter 5 — but treat it like any other type for now.

All five together, from code/types_demo.cpp:

    int year = 2026;
    double cosmological_constant = 1.1056e-52;
    bool faith_active = true;
    char category = 'G';
    string verse = "1 Peter 3:15";

    cout << boolalpha;

    cout << "int:    " << year << endl;
    cout << "double: " << cosmological_constant << endl;
    cout << "bool:   " << faith_active << endl;
    cout << "char:   " << category << endl;
    cout << "string: " << verse << endl;

Actual output:

int:    2026
double: 1.1056e-52
bool:   true
char:   G
string: 1 Peter 3:15

That cout << boolalpha; is doing real work. Without it a bool prints 1 or 0, because that’s how it’s stored. Send boolalpha once and every boolean printed afterward comes out as true/false. Project 1 requires that, so put the line near the top of main and forget it.

1.14 — Declaring, Initializing, Assigning — and const

Three related operations. Don’t blur them.

Declaration creates a variable with no value: int score; — legal, and score now exists, but its value is undefined, whatever bits were last in that memory. Reading it is a classic bug; -Wall usually (not always) warns.

Initialization creates it and gives it a value: int score = 0;. Do this almost every time.

Assignment changes an existing variable:

int score = 0;       // initialization
score = 10;          // assignment
score = score + 5;   // assignment — score is now 15

Stare at that last line. score = score + 5 does not mean “score equals score plus five” the way algebra means it. It means take the current value of score, add 5, store the result back. Read it right to left. There’s a shorthand for exactly that: score += 5;, and likewise -= and *=.

Coach’s Note — = in C++ is not the equals sign from math class. It’s a verb: it takes the value on the right and puts it in the box on the left. The math-class equals sign is ==, which arrives in Chapter 2. Wire that in now — one equals sign stores, two equals signs ask — and save yourself a year of confusion.

const — the value that isn’t allowed to move

Some values must not change: the number of weeks in a course, a conversion factor, the bounds of a range. Mark them const and the compiler enforces it.

const int WEEKS_IN_COURSE = 8;
const double HOURS_PER_WEEK = 12.0;
// WEEKS_IN_COURSE = 16;   // ❌ won't compile: assignment of read-only variable

Three reasons to use it freely: it documents intent, it catches your own mistakes at compile time when they’re cheap, and it gives numbers names — 9.9e-39 buried in a formula is a mystery, RANGE_WIDTH is not. Convention in this book: const names in ALL_CAPS, ordinary variables in snake_case, so you can see at a glance which values in a formula can move.

Actual output of code/declare_init_const.cpp:

start:      0
after = 10: 10
after +5:   15
after += -= *=: 34
weeks:      8
hours/week: 12
total:      96

Two things to notice. HOURS_PER_WEEK was initialized to 12.0 and printed as 12, because C++ drops trailing zeros by default — which is why §1.18 exists. And the whole course is 96 hours of work. That number is not a metaphor.

1.15 — Arithmetic

The operators look like you’d expect, from code/arithmetic_demo.cpp:

    int sum       = 3 + 4;     // 7
    int diff      = 10 - 6;    // 4
    int product   = 5 * 6;     // 30
    int quotient  = 15 / 4;    // ❌ 3, not 3.75 — see §1.16
    int remainder = 15 % 4;    // 3 (the leftover after dividing)

That last one is modulo, % — the remainder of integer division. It answers “what’s left over?” questions: is this even (n % 2 == 0), what’s the last digit of the year (year % 10), is this every fifth time (i % 5 == 0). Modulo is integer-only; 7.5 % 2 does not compile, and §1.22 has the exact error.

Doubles do the same math and keep the decimals. Actual output:

3 + 4   = 7
10 - 6  = 4
5 * 6   = 30
15 / 4  = 3   <-- int division
15 % 4  = 3   <-- remainder
3.0 + 4.0 = 7
3.0 * 4.0 = 12
3.0 / 4.0 = 0.75
2026 % 10 = 6   <-- last digit of the year
2026 % 2  = 0   <-- 0 means even

Look at 3.0 + 4.0 = 7. That’s a double holding exactly 7.0, printed bare because C++ suppresses trailing zeros. The value is a double; only the display is plain. Don’t let a display convince you a type changed.

1.16 — The Integer-Division Trap

This is the one. It is the single most common source of “my math is broken” in beginning C++, and it will show up in your Project 1 report.

Divide two ints with / and C++ hands back an int with the fraction truncated — chopped, not rounded:

int a = 7;
int b = 2;
int result = a / b;      // 3. The .5 is GONE.

Two doubles give a double (7.0 / 2.0 is 3.5). An int divided by a double promotes the int first and also gives 3.5. Here’s the version that catches everyone:

int constants_in_range = 7;
int constants_examined = 9;
double fraction = constants_in_range / constants_examined;   // ❌ 0, not 0.777...

Seven ninths is about 0.78. This prints 0, because the division is evaluated first under integer rules — 7 / 9 is 0 — and only then stored into the double. Declaring the destination double does not retroactively fix the division. The damage is done before the assignment.

The fix: force at least one operand to double before dividing. Four ways, all correct:

double fix_cstyle   = (double)a / b;                 // C-style cast
double fix_cppstyle = static_cast<double>(a) / b;    // C++-style — preferred
double fix_divisor  = a / (double)b;                 // cast the divisor instead
double fix_multiply = a * 1.0 / b;                   // multiplying by 1.0 promotes a

Pick one; don’t write all four in real code. This book prefers static_cast<double> because it announces loudly, in the source, that a conversion is happening on purpose. The file code/integer_division.cpp runs them side by side. Actual output:

a = 7, b = 2
Trap (int / int):                3
C-style cast:                    3.5
static_cast<double>:             3.5
Cast the divisor:                3.5
Multiply by 1.0:                 3.5
double = int / int (still bad):  3

Memorize that last line. double looks_right_but_isnt = a / b; still prints 3. The variable genuinely is a double — holding 3.0 — but the fraction died one step earlier.

Coach’s Note — This bug is coming for you in Project 1’s report half. Any ratio is a candidate. When in doubt, declare the inputs as double; when they really should be integers but the result needs a fraction, cast one. Then test with numbers whose answer you know: 7 and 2 must give 3.5, and if your program says 3 you found the bug before your grader did.

The deeper point. That code compiles. It runs. It produces an answer. The answer is silently wrong because the type of an intermediate step was almost-right. That’s the canonical example of “confident, fluent, productive — and slightly wrong about something foundational.” Watch for the analogous move elsewhere. Not every wrong answer announces itself.

1.17 — Mixed Types and static_cast

Implicit conversion is the compiler converting without being asked:

int years = 8;
double weeks = years * 12.0;   // years is promoted to double for the math

Rule of thumb: C++ converts the “smaller” type toward the “larger” so nothing is lost during arithmetic. int → double is safe. The other direction is not:

double price = 9.99;
int rounded = price;    // rounded is 9. Not 10.

Two things about that line, and the second is the sharp one. It truncates, it does not round — 9.99 becomes 9, -3.7 becomes -3. And with -Wall -Wextra it compiles without a single warning. I checked; you’d need -Wconversion, which nothing turns on by default. That’s silent data loss with nothing to alert you.

Explicit conversion says you meant it:

int rounded = static_cast<int>(price);   // 9, on purpose, and the reader can see it

static_cast<int>(price) means “express this as an int; I take responsibility for anything lost.” The older (int)price does the same here, but static_cast is preferred in modern C++: it’s easy to search for, and it’s ugly enough to notice — which is what you want from an operation that throws data away.

Coach’s Note — Beginners over-cast, sprinkling static_cast<double> everywhere just in case. Don’t. A cast tells the reader something is being converted deliberately; an unnecessary one is clutter that lies. Cast where you need it — chiefly to escape the integer-division trap — and let implicit promotion handle the rest.

1.18 — Making Numbers Presentable: fixed and setprecision

By default cout prints a double with six significant digits and drops trailing zeros. Fine for scratch work, wrong for anything a human reads. The tools live in a new toolbox: #include <iomanip>.

• setprecision(n) alone sets significant digits — total digits from the first non-zero one.
• fixed switches to fixed-point notation, after which setprecision(n) means digits after the decimal point.
• setw(n) sets a minimum field width for the next item only, padding with spaces on the left.

fixed and setprecision are sticky — they persist for everything printed afterward. setw applies once and resets. Actual output of code/formatting_demo.cpp:

default (6 significant digits):
  margin = 0.585859
  gift   = 1234.5
  tiny   = 5.9e-39

setprecision(3) alone = 3 SIGNIFICANT digits:
  margin = 0.586
  gift   = 1.23e+03

fixed + setprecision(2) = 2 digits AFTER the point:
  margin = 0.59
  gift   = $1234.50
  tiny   = 0.00   <-- fixed is wrong for tiny numbers

setw pads the NEXT item only:
|      Name|  Reps|
|    Marcus|    12|
|      Maya|     9|

Four lessons in one screen, all of which you need before formatting your Project 1 report:

1. setprecision(3) alone turned 1234.5 into 1.23e+03 — three significant digits isn’t enough to write it plainly, so the stream switched to scientific. If you wanted money, that’s a bug.
2. fixed plus setprecision(2) gives $1234.50, trailing zero included. That’s the money recipe.
3. fixed is wrong for very small magnitudes: 5.9e-39 printed as 0.00, which erases the value rather than rounding it. When your numbers span many orders of magnitude, leave the default alone.
4. setw gives real columns, unlike \t: setw(10) << "Marcus" right-aligns in a ten-wide field no matter how long the text is.

Lesson 3 is why the Project 1 report needs a decision rather than a formula: format the ratios with setprecision, and let the physical values print in their default scientific form.

1.19 — Booleans Are Arithmetic (a One-Week Trick)

Two facts matter for Project 1’s report half.

Comparisons produce booleans.

bool in_range = (measured_value >= LOW_BOUND) && (measured_value <= HIGH_BOUND);
bool old_enough = (age >= 18);

The comparison operators are <, >, <=, >=, == (equal), != (not equal). Full treatment in Chapter 2; this table is here so this week’s work is possible:

In C++, true is 1 and false is 0 in arithmetic. So you can multiply by a boolean:

char class_char = 'W';
int base_attack = 10;

int warrior_bonus = (class_char == 'W') * 5;   // 5 if 'W', otherwise 0
int mage_bonus    = (class_char == 'M') * 3;   // 0 here

int total_attack = base_attack + warrior_bonus + mage_bonus;   // 15

Exactly one comparison is true, so exactly one term is non-zero. It’s a strange-looking trick, and it’s exactly what you do when you need to choose between values and don’t have if yet — which, this week, you don’t.

Coach’s Note — A one-week stopgap. Chapter 2 gives you if and you should switch immediately, because if reads far more clearly. The point of learning the stopgap is to feel, once, that arithmetic and logic aren’t two different things inside a computer. They’re the same thing from two sides.

1.20 — Putting It Together

One program using everything above: all five types, const bounds, a bool built from comparisons and printed with boolalpha, setprecision, and the integer-division trap standing next to its fix. It’s code/fine_tuning_demo.cpp.

The subject is what Project 1’s report half is built on. Nobody on any side of the religion-and-science conversation seriously disputes that a handful of physical constants sit within extraordinarily narrow ranges, and that small changes give you a universe in which life as we know it cannot exist. What people disagree about is what to make of that. This program settles nothing; it does the arithmetic and makes the numbers legible, which is the only honest thing a hundred lines of C++ can do for a fifty-year-old debate.

    string constant_name = "gravitational_coupling";
    double measured_value = 5.9e-39;
    char category = 'G';

    const double LOW_BOUND = 1.0e-40;
    const double HIGH_BOUND = 1.0e-38;

    int constants_in_range = 7;    // sample data for the exercise
    int constants_examined = 9;    // sample data for the exercise

    double range = HIGH_BOUND - LOW_BOUND;
    double margin = (measured_value - LOW_BOUND) / range;

    bool life_permitting =
        (measured_value >= LOW_BOUND) && (measured_value <= HIGH_BOUND);

    // ❌ int / int — the fraction is destroyed before the double ever sees it
    double fraction_trap = constants_in_range / constants_examined;

    // ✅ one operand promoted to double first
    double fraction_fixed =
        static_cast<double>(constants_in_range) / constants_examined;

    cout << boolalpha;
    cout << "  Margin in range:     " << setprecision(4) << margin << endl;
    cout << "  Life-permitting:     " << life_permitting << endl;

Actual output of the full program:

+------------------------------------------------+
|               FINE-TUNING REPORT               |
+------------------------------------------------+
  Constant:            gravitational_coupling (G)
  Measured value:      5.9e-39
  Life range:          [1e-40, 1e-38]
  Range width:         9.9e-39
  Margin in range:     0.5859
  Life-permitting:     true
  Constants in range:  7 of 9
  Fraction (trap):     0
  Fraction (fixed):    0.7778
+------------------------------------------------+

Read the last two data rows again. Same numbers, same division, one cast — 0 versus 0.7778. If you remember one thing from Week 1, remember that those two lines came from the same arithmetic.

Two smaller notes. LOW_BOUND was written 1.0e-40 and printed 1e-40 — display, not value. And margin came out right with no cast anywhere, because measured_value, LOW_BOUND, and range are all already doubles. The trap fires only when both operands are integers.

Type it in, compile, run. Then delete static_cast<double> from the fraction_fixed line and watch a correct program become a wrong one that still compiles, still runs, and still looks confident.

1.21 — A Coach’s Note on AI Tools

You’re taking this course in an era where AI assistants write code on request. We won’t pretend they don’t exist and we won’t ban them. But here’s the rule, non-negotiable if this course is going to be worth anything to you:

AI is a sparring partner. It is not a substitute for reps.

A boxer who only spars with a coach holding pads never builds the conditioning to last twelve rounds. Used well, AI accelerates you — explaining an error, suggesting an approach. Used as a substitute for reps, it leaves you helpless the moment you don’t have it. And eventually you won’t: the exam, the interview whiteboard, the 3 a.m. incident where the model confidently invents a function that doesn’t exist.

There’s a specific risk in an asynchronous course worth naming plainly. When nobody is watching, the distance between “I asked it to explain this” and “I asked it to write this” collapses very quietly. The only thing between you and finishing eight weeks with no skill is your own decision, made about twenty times a week, usually late at night.

1. First, attempt every concept, exercise, and project yourself, from scratch, AI off.
2. Then, optionally, use AI to review what you wrote, explain an error you couldn’t decipher, or expand your thinking.
3. Never paste AI-generated code into a project unless you can explain every line out loud, unprompted.

Rule 3 is also the exam policy: both exams include a written component about your own design decisions, and code you can’t explain is treated as not submitted. That isn’t moralizing; it’s just what the assessment measures.

1.22 — Common Bugs (Week 1 Edition)

You’ll hit some of these this week, possibly all. Recognize them and they cost thirty seconds; ignore them and they cost thirty minutes. The text below is real GNU g++ output — the compiler family OnlineGDB runs — captured from actual broken programs. Your line and column numbers will differ.

1. error: 'cout' was not declared in this scope

note: 'std::cout' is defined in header '<iostream>'; this is probably fixable by adding '#include <iostream>'

Means: The compiler has never heard of cout — you forgot #include <iostream>. Fix: Add the include. Read the note: line; g++ is telling you the answer.

2. error: 'cout' was not declared in this scope; did you mean 'std::cout'?

Means: Nearly the same message, different cause. The include is there but using namespace std; is missing, so the name exists only inside the std namespace. Fix: Add using namespace std; after your includes, or write std::cout. The did you mean 'std::...' tail is how you tell this from bug 1.

3. error: expected ';' before 'return'

Means: A missing semicolon, reported at the end of the line before the one the compiler was reading. Fix: Look at the line above the one named in the message. That’s almost always where the semicolon goes.

4. undefined reference to 'main' / collect2: error: ld returned 1 exit status

Means: Your code compiled but the linker couldn’t find main — usually Main, mian, or main with no int in front. Fix: Exactly int main() { ... }. C++ is case-sensitive.

5. error: missing terminating " character

Means: An unclosed string literal; everything after the opening quote got swallowed. You’ll also get a nonsense second error. Fix: Close the quote, recompile, and ignore the aftershocks.

6. error: 'nmae' was not declared in this scope; did you mean 'name'?

Means: A typo in a variable name. Fix: Spell it the way you declared it. g++ frequently guesses the intended name, as it did here.

7. error: invalid conversion from 'const char*' to 'char' [-fpermissive]

Means: Double quotes where a char was expected: char grade = "A";. "A" is a string, 'A' is a character. Fix: Single quotes for one character, double for text. The same error ending to 'int' means you assigned a string literal to a number, like int year = "2026";. A related one, warning: multi-character character constant, means you put two letters in single quotes ('ab') and the value you get back is garbage.

8. error: invalid operands of types 'double' and 'int' to binary 'operator%'

Means: Modulo on a floating-point number. % is integers only. Fix: Use int operands, or rethink — for doubles you usually want subtraction or division, not a remainder.

9. error: expected '}' at end of input (with note: to match this '{')

Means: An unclosed brace. The note: points at the { that never got a partner. Fix: Count your braces. Consistent indentation makes this visible instead of archaeological.

10. error: assignment of read-only variable 'WEEKS_IN_COURSE'

Means: You assigned to a const. Refusing is the entire purpose of const. Fix: Either you meant a normal variable (drop the const) or you meant not to assign (drop the assignment). Decide which; don’t delete the keyword reflexively.

11. warning: 'score' is used uninitialized [-Wuninitialized]

Means: You declared int score; and read it before assigning. The value is whatever bits were there. Fix: Initialize on declaration. It’s a warning, so the program still builds and runs — with garbage — and the compiler can’t always spot it.

12. warning: unused variable 'reps' [-Wunused-variable]

Means: Declared and never used. Harmless at runtime, but it costs you the “compiles with no warnings” line on every rubric in this book. Fix: Use it or delete it. Usually it’s a rename that left the old one behind.

13. error: 'setprecision' was not declared in this scope

Means: A formatting manipulator without its toolbox. Fix: #include <iomanip>. Note fixed and boolalpha live in <iostream> and don’t need it — only setprecision and setw do, which is why this appears halfway through prettying up your output.

14. Your program ends before you can type anything.

Means: You wrote the cout prompt and forgot the cin under it. Fix: Every prompt needs a matching read. Read prompts and cins as pairs.

15. You type a word where a number was expected, and everything after it breaks.

Real run of a program reading an int then a string, fed twelve and Denver:

Age: City: age=[0] city=[unset]

Means: cin >> age couldn’t parse twelve. Since C++11 the variable is set to 0 and the stream enters a failed state — and every later read silently does nothing, which is why city kept its initial value. Both prompts printed back to back because the program never paused again. Fix: This week, ask for the right kind of input and type it. (The proper repair is cin.clear() plus cin.ignore(), which needs if — Chapter 2.) If later inputs seem “skipped,” suspect an earlier failed numeric read.

16. Your getline comes back empty.

Real run, fed 3 and Codex Sinaiticus:

Copies: Manuscript: copies=[3] manuscript=[]

Means: A cin >> before the getline left the newline in the buffer, and getline read up to it — nothing. Fix: cin.ignore(); between the >> read and the getline. See §1.10. Related: if cin >> name captured only the first word, that’s the same buffer at work — use getline for anything that may contain a space.

17. Your bool prints 1 or 0 instead of true / false.

Means: C++‘s default; booleans are stored as 1 and 0. Fix: cout << boolalpha; once near the top of main. Project 1 requires this.

18. Silent wrong answers: division and truncation.

Means: Two ints divided give an int (§1.16), and a double assigned into an int truncates (int rounded = 9.99; gives 9). Neither produces any warning at -Wall -Wextra — the second needs -Wconversion, which nothing turns on by default. Fix: static_cast<double> one operand before dividing; static_cast<int> when you genuinely mean to truncate, so your reader can see it was on purpose.

Coach’s Note — Keep this list open in a second tab all week and add your own entries. By Week 8 you’ll have a personal debugging cheat sheet worth more than the textbook, because it’s indexed by the mistakes you actually make.

1.23 — Reps

The full set is in the exercises, and every rep there ships with the exact output it should produce so you can grade yourself. Three to do right now:

Rep A. Modify hello.cpp to print three lines: your name, where you live, what you had for breakfast. Verify: three lines, each ending where you intended, no blank lines you didn’t ask for.

Rep B. Ask for a name with getline and a rep count with cin >>, then print NAME did N reps. Verify: given Marcus Aurelius and 12, the output line is exactly Marcus Aurelius did 12 reps. If the name comes back partial, re-read §1.9; if empty, re-read §1.10.

Rep C. Store 7 and 9 in two ints and print their quotient twice — plain integer division, then cast to double. Verify: the two lines print 0 and 0.777778.

1.24 — Checkpoint: Can You Do This Yet?

Close the book. Open a blank file. No notes, no search, no AI. Twenty minutes. Write these eight things from memory; if you have to peek at anything, that item is a miss.

1. The complete skeleton of a program that prints one line — includes, main, cout, return 0, closing brace — typed from nothing.
2. A prompt-and-read pair putting a one-word answer into a string.
3. A prompt-and-read pair putting a full line with spaces into a string, immediately after reading a number. (You must produce the cin.ignore() unprompted.)
4. One declaration of each of the five types, each initialized on the same line and printed with a label — with the bool printing as true, not 1.
5. A const declaration, plus one sentence on what happens if you assign to it.
6. Two ints divided so the answer comes out as a decimal, written two different ways.
7. A double printed with exactly two digits after the decimal point.
8. One sentence each: what << does, what >> does, what “was not declared in this scope” means.

Pass bar: seven of eight, with items 1, 3, and 6 among them. Those three are non-negotiable — item 1 is every program you’ll write this term, item 3 is how Project 1 reads a multi-word constant name, item 6 is the trap that silently wrecks the report.

If you didn’t clear the bar, do not start the project. Go back: §1.6 and §1.9–§1.10 for items 1–3, §1.13–§1.14 for 4–5, §1.16 for 6, §1.18 for 7. Re-drill the matching reps, then take this again with different values. Half a session of re-drilling now is cheaper than a full session lost debugging a project you weren’t ready to write. Nobody else is going to catch this for you — catching it is what this section is for.

1.25 — When You’re Stuck (and Nobody’s in the Room)

You will get stuck this week. There’s no hand to raise. So climb this ladder a rung at a time, and don’t skip to the top.

Rung 1 — Read the first error out loud, all of it. Then look at the line above the one it names. Half of this week’s errors are a missing semicolon or a missing include, and both announce themselves plainly. Cost: 60 seconds.

Rung 2 — Check it against §1.22. Eighteen entries with real text. If your message is there, you’re done. Cost: 2 minutes.

Rung 3 — Print the variable. If it compiles but the output is wrong, you have a value problem, not a syntax problem. Add cout << "DEBUG margin = " << margin << endl; before the place it’s used, then another earlier. You’re bisecting: find the first line where the value is already wrong, and the bug is just above it. That’s most of professional debugging, and this week’s tools are enough for all of it.

Rung 4 — Cut it down to a minimal reproduction. New file, only the broken part, hard-coded values instead of cin. Five lines that show the bug beat two hundred that contain it. Often the bug reveals itself while you’re doing this — that’s the technique working, not a waste.

Rung 5 — Explain it to the duck. Out loud, to an object, in complete sentences: “This variable holds the number of constants. I divide it by this one. I expect zero point seven eight. I get zero…” Finish the sentence and you’ll usually hear the answer come out of your own mouth — the bug is nearly always a gap between what you think the code says and what it says.

Rung 6 — Take a twenty-minute walk. Not twenty hours. Twenty minutes, away from the screen. Productive struggle builds skill; grinding past an hour on one bug does not.

Rung 7 — Post to the discussion board, in this shape. Vague posts get vague answers, slowly.

Title: [Wk1] getline returns empty after reading an int

What I'm trying to do:  read a count, then a multi-word manuscript name.
What I expected:        Manuscript: Codex Sinaiticus
What I actually got:    Manuscript:
Exact error/output:     (paste it, all of it)
Smallest code that shows it: (paste 5-10 lines, not your whole file)
What I already tried:   §1.10; put cin.ignore() after the getline (no change)

Someone in your cohort hit the same wall this week. That format gets an answer in an hour instead of a day — and writing it solves the problem outright often enough to be worth doing even if you never post it.

Rung 8 — Email the instructor. Same shape as Rung 7, plus your OnlineGDB share link and the tier you’re targeting. Subject: [Accelerated Coding 1] Wk1 — <one-line symptom>. Send it as soon as you’ve genuinely climbed rungs 1–6. Don’t sit on it for three days out of politeness; in an eight-week course, three days is a fifth of the material.

Coach’s Note — The biggest difference between students who thrive here and students who drown isn’t talent. It’s the first ten minutes of being stuck. The drowners freeze or start changing lines at random; the thrivers run the ladder. Both are trained responses. Pick which one you’re training.

1.26 — This Week’s Project

You’re ready for P1 — Apologist’s Card & Fine-Tuning Report, in Project 1, due at the end of Week 1. Write it in two sittings, because it’s genuinely two programs’ worth of ideas in one file.

The card half is your starting line. Every sport has player cards — baseball cards, kits with a name on the back, a boxer’s stat card. Apologists could use one. Yours prints who you are, where you’re from, and the question you’d most like to think clearly about by Week 8. Tools: cout, cin, getline, string, and your eye for spacing — §1.6 through §1.10.

The report half makes numbers legible: a physical constant, its measured value, the bounds of the life-permitting range, and the statistics derived from them. Tools: all five types, const, arithmetic, static_cast, boolalpha, setprecision — §1.13 through §1.20.

They belong in one project for the same reason they belong in one chapter. The card is I/O with almost no arithmetic; the report is arithmetic with almost no I/O. Real programs are both, and the seam between them — a value the user typed, landing in a variable of a type you chose, coming back out formatted — is exactly what this week was about.

Two warnings. The integer-division trap will try you somewhere in the report’s ratios; test with numbers whose answer you already know. And take the card seriously: in Week 8 you’ll look at the question you wrote and either be glad you were honest or wish you had been.

Exact requirements, tiers, rubric, and submission format are in Project 1. Read the rubric before you write code.

1.27 — Coach’s Final Word for Week 1

If this chapter felt like a lot, it’s because it was two. That’s the deal you signed up for: nothing is cut, so the hours double.

But look at what you can do that you couldn’t do on Monday. You can make a machine talk, listen, remember what it heard, do arithmetic on it, and hand back an answer a human can read. You can read a compiler error without your stomach dropping. That isn’t “getting started with C++” — that’s the whole first pillar, and every remaining week is built on it.

You also know the game now: build memory, ask the right questions, repeat. Two of those are still ahead. Both arrive next week.

One last thing, and it’s what this edition exists to say. Nobody will notice if you skip the reps. Nobody sees whether you took the Checkpoint honestly. In eight weeks the only person who knows how much of this actually lives in your hands is you — and then, all at once, the midterm. So do the reps. Type the examples instead of pasting them. Break each one on purpose. Ship the project at a tier you can defend out loud.

Welcome to the sport. Let’s get to work.

Up next: Work every rep in the exercises — each one states the exact output to expect, so grade yourself honestly. Then build P1 — Apologist’s Card & Fine-Tuning Report in Project 1. After that, Chapter 2, where programs start making decisions and doing things more than once.