Module 1 — C++ and the OOP Mindset¶

After this module you can explain why object orientation exists at all, describe how your source file becomes a running program, and write, compile and run C++ using the course's own command.

At a glance¶


Prerequisites	None. You should be able to write a function and use an array in some language — see Prerequisites
Estimated study time	6–8 hours
Lab	Lab 1 — the procedural baseline
Exercises	Three tiers — warm-up, core, challenge
Cognitive levels	L1 Understand → L4 Analyze — exit level L3 Modify
Self-assessment	Module quiz

Why this module matters¶

Almost every beginner is taught what a class is before being told why anybody wanted one. That ordering makes object orientation feel like arbitrary ceremony — extra syntax, extra files, no visible benefit.

This module fixes the order. You will build a small program the procedural way first — global arrays, free functions, a growing list of parameters — and extend it. You will feel the friction. Only then does object orientation appear, as the obvious answer to a problem you have just experienced rather than a rule someone told you to follow.

It also covers the mechanics the rest of the course silently assumes: what #include actually does, what the compiler and the linker each contribute, and why std:: sits in front of everything.

Learning objectives¶

By the end of this module you will be able to:

[L1 Understand] Describe the stages that turn a .cpp file into a running program — preprocessing, compilation, linking — and say what each stage does.
[L2 Apply] Compile and run a program using the course's exact command, and explain what each flag in it is for.
[L2 Apply] Write a C++ program using #include, main, std::cout, user-defined functions, and const.
[L1 Understand] Distinguish a value, a reference and a pointer well enough to read ordinary C++ code confidently.
[L4 Analyze] Explain procedural decomposition, and name its characteristic problems: global state, long parameter lists, and data separated from the behaviour that operates on it.
[L3 Modify] Change an existing program — add a field to a record — predict the effect before running it, and count what had to change.
[L1 Understand] State the four pillars of object orientation — abstraction, encapsulation, inheritance, polymorphism — and give a concrete example of each.
[L2 Apply] Identify candidate classes and their responsibilities in a plain-English problem description (nouns suggest types, verbs suggest operations).
[L1 Understand] Explain why the standard library lives in the std namespace, and why using namespace std; is avoided in headers.
[L3 Modify] Tell a compile error from a link error from a runtime error, and predict which one a given mistake will produce.

This module's exit level is 3 Modify: you are finished when you can change a program and predict the effect — not when you can recite section 6.

Core concepts¶

Translation unit — a source file after preprocessing: everything the compiler actually sees.
Preprocessing — text substitution before real compilation. #include pastes a file in; macros are replaced.
Compilation — translating one translation unit into machine code.
Linking — joining compiled units and libraries into one executable, and resolving every name that was used but defined elsewhere.
main — the entry point. Its return value, conventionally 0, is the exit status reported to the operating system.
Namespace — a named region that qualifies identifiers. The standard library uses std, which is why you write std::cout.
Function — a named block taking parameters and producing a result. The unit of behaviour in procedural design.
const — a promise the compiler enforces: this value will not change.
Reference — another name for an existing object; cannot be null and cannot be reseated.
Pointer — a variable holding an address; may be nullptr.
Procedural decomposition — splitting a program into actions.
Object-oriented decomposition — splitting a program into things, each holding its own data and the operations on that data.
Class and object — the type and one instance of it.
Abstraction — exposing what a thing does while hiding how.
Encapsulation — keeping data and the operations on it together, and controlling outside access.
Inheritance — defining a new type in terms of an existing one.
Polymorphism — one interface, several behaviours chosen at run time.
Domain analysis — reading a problem description and finding the types hiding in it.

Module contents¶

Every module in this course has the same sections, so you always know where to look. Sections appear here as they are written — this repository never contains placeholder files.

Section	What it contains
Introduction (this page)	Overview, prerequisites, objectives, concept inventory
Concepts and explanations	The pipeline, why procedural code resists change, the four pillars, domain analysis, values and references
Worked examples	Five annotated programs, each with a prediction prompt before its output
Code examples	`examples/module-01/` — four programs, two with captured output
Misconceptions and mistakes	Six wrong mental models, and the errors everyone makes
Debugging	Reading a compiler message, a worked diagnosis, and the escalation ladder
Exercises	Three tiers, nine tasks, each stating what success looks like
Lab 1	The direct procedural baseline — deliberately clumsy, with a written reflection
Challenge problems	Paper-only design work, including the bridge into Module 2
Self-assessment	Nine questions with answers, and a re-test schedule
Summary	What must be retained, the terms to be able to define, and the final checklist
Further reading	Books and official documentation

What you can do after this module¶

Set up a compiler and build C++ from the command line without help.
Read a small program and say what it will print, or why it will not build.
Take a plain-English problem and list candidate classes and responsibilities for it — the first step of every design in the rest of this course.
Explain, in your own words and without jargon, why the procedural version of your Lab 1 program resists change.

Where this is used later¶

Compile vs link errors return throughout, and are examined properly in Module 16 when a program is split across many files.
Namespaces reappear as soon as you write your own, and again in Module 12, where the standard library becomes a daily tool.
The four pillars are the syllabus: abstraction and encapsulation, inheritance, polymorphism.
Domain analysis is reused in every lab, and formalised with UML in Module 15.

Common mistakes to watch for¶

Symptom	Cause
`error: expected ';' before '}'`	A missing semicolon on the line above — look one line earlier than the report
`error: 'cout' was not declared in this scope`	`#include <iostream>` is missing, or `std::` is missing
`fatal error: iostream: No such file or directory`	Compiled with `gcc` instead of `g++`
`undefined reference to 'main'`	No `main`, or the wrong file was named in the command
The program builds but prints nonsense or crashes	Undefined behaviour: out-of-bounds access, an uninitialised value, or a dangling pointer — recorded now, explained in Module 4 and Module 10

Skills checklist¶

Levels this module works at: [L1 Understand → L4 Analyze] — see How you will learn.

Tick an item only when the evidence exists:

[ ] I can explain the three stages and name which one failed — evidence: the four deliberate breakages from exercise C2, each labelled with its stage
[ ] I can write, compile and run a program from a blank file — evidence: exercise C1's two summing functions, building with no warnings
[ ] I can predict a program's output before running it — evidence: a written prediction beside the real output, with any difference explained
[ ] I can name the three problems of procedural decomposition — evidence: Lab 1's reflection, citing the specific lines
[ ] I can measure the cost of a change — evidence: exercise C3's two numbers, for the parallel-array version and the class version
[ ] I can state the four pillars with an example each — evidence: an example per pillar that would stop working if the pillar were removed
[ ] I can list candidate classes for a problem description — evidence: challenge 1, with responsibilities rather than names
[ ] I can tell the three failure kinds apart — evidence: the diagnosis in exercise C2, and a link error fixed in my own code

Suggested next step¶

Next: Module 2 — Classes and Objects · All modules: Modules index · Before this module: Start Here