cadence_learn
the_c++_track / level 02 of 15 ▶ 16 min

six lines, taken apart.

Every piece of hello world is load-bearing, and every piece comes back in everything you write afterwards. Click each one and find out what it is actually for.

after this level you'll be able to
  • Say what every line of a hello world program is for
  • Compile and run a program, and know why silence means success
  • Never again run a stale program after forgetting to compile
the first one

six lines, and every one of them is doing something

Here is the program every programmer has written first, in every language, for fifty years. It puts one line of text on the screen. That is all it does — and it is still worth taking apart properly, because every single piece of it comes back in everything you write afterwards.

Open VS Code, make a file called hello.cpp in the folder you made last level, and type this. Type it, do not paste it. Typing it is how you find out that the compiler cares about characters you would not have noticed.

▤ lab · take it apart

Click any highlighted piece of the program to find out what it is for.

#include <iostream> using namespace std; int main() { cout << "Hello, world!" << endl; return 0; }
start here

Click any coloured part above. There are nine pieces and every one of them is load-bearing — take any of them out and the program either refuses to compile or stops making sense.

Nine pieces to look at.
◈ ask an ai about this

“Explain every line of a C++ hello world program to someone who has never programmed. What does each part do?”

chatgpt ↗ claude ↗

now run it

the loop you will do a thousand times

Save the file. Then in Terminal, from the folder the file is in:

terminal
$ g++ -std=c++17 -Wall hello.cpp -o hello
# nothing at all happens. that is success.
$ ./hello
Hello, world!

The silence after the first command is the part that confuses everyone. A compiler that has nothing to say is a compiler that found nothing wrong. It does not congratulate you. It just makes the file and stops.

you edit one file and run a different one
YOU EDIT hello.cpp text · you can read it COMPILE g++ TRANSLATES -std=c++17 -Wall reads every character before producing anything silence = it worked MAKES A SECOND FILE hello machine code · runs RUN ./hello change anything → you must compile again Editing the file does not change the program. The running program is a separate file made at compile time. “I fixed it and it still does the old thing” is almost always this: the fix was saved, and never compiled.
Two files, and beginners routinely do not realise there are two. You edit one and run the other, and nothing you type reaches the running program until you compile again.
the mistake you will make this week

You will change the code, save it, run ./hello, and see the old behaviour — then spend twenty minutes wondering why your fix did nothing. You forgot to compile. Everyone does this. The habit that kills it: never run without compiling first, on one line:

terminal
$ g++ -std=c++17 -Wall hello.cpp -o hello && ./hello

The && means only if that worked. If the compile fails, it does not run the stale program — it stops and shows you the error. Use this from now on and one whole category of confusion never happens to you.

◈ ask an ai about this

“Why does compiling print nothing when it works, and why do I have to type ./ before my program name?”

chatgpt ↗ claude ↗

what you already know

you have seen all of this before

Look back at what the program does. cout puts something on the screen — that is one step in a sequence from level 3. The semicolons end each instruction, which is how the machine knows where one ends and the next begins — the literal machine from level 1, needing you to be exact. And int main() is a function from level 2: a named piece of work, with a kind of answer it hands back.

That is why the twelve levels came first. None of this is new thinking. It is the thinking you already did, written down in a notation with strict punctuation.

do this together

break it on purpose, one piece at a time

☶ two people · 15 minutes · one laptop

Delete one character. Predict what happens. Then compile.

person a — the vandal

Remove exactly one thing: a semicolon, a brace, the #include line, one quote mark. Do not say which.

person b — the forecaster

Before compiling, say out loud what you think the compiler will complain about. Then compile and read the real message together.

Do this six or seven times and something useful happens: compiler errors stop being a wall of noise and start being a small set of familiar complaints. You will meet every one of these for real in week two — and having broken it yourself on purpose, calmly, is completely different from meeting it at midnight when it is not your fault.

what to keep

three things worth remembering

01

Silence is success

A compiler with nothing to say found nothing wrong. It never congratulates you.

02

There are two files

You edit one and run the other. Saving changes nothing until you compile again.

03

Always compile && run

One line, joined by &&, so you can never accidentally run yesterday’s program.

check yourself

3 questions before you move on

Not recall — these are the shapes an exam actually uses. Every answer below was produced by compiling and running the code, so if you disagree with one, the compiler is the one to believe.

▢ check yourself3 questions

Have a real go before revealing. Being wrong here is worth more than being right in three weeks.

01

You compile and Terminal prints absolutely nothing. What happened?

02

You fix a bug, save the file, run ./hello — and see the OLD behaviour. Why?

03

What is int main()?

answered: 0 of 3right first time: 0
Stuck? Peter reads these personally and replies to your email.
Ask Peter →