Module 1 — Summary

The essentials

• Preprocessing, compilation and linking are three separate stages, and they fail differently. The compiler catches what you wrote wrong; the linker catches what is missing; neither catches a wrong idea that happens to compile.
• A successful compile is silent. No output means it worked.
• Identify the stage before changing any code. error: is the compiler reading your file; undefined reference is the linker looking for something that does not exist; no message at all means the program ran and misbehaved.
• Procedural decomposition runs into three characteristic problems as a program grows: global state that anything can corrupt, long parameter lists that must be threaded through every function, and data separated from the behaviour that knows the rules about it.
• Object-oriented decomposition puts data and its operations in one unit, so the rules have a home and the compiler can check how a type is used.
• The four pillars are four problems solved, not four definitions: abstraction hides representation, encapsulation protects a rule, inheritance states what is common, polymorphism lets one loop handle every kind.
• Candidate types come from the problem description — nouns for types, verbs for operations, rules for invariants — and each candidate must be justified by a responsibility that fits in one sentence.
• Values, references and pointers are three different things. *p = 7 changes the object p points at; a value parameter changes nothing outside the function.
• Undefined behaviour may appear to work. "It ran on my machine" is never evidence of correctness.
• Objects are a choice, not an obligation. A 30-line procedure with no rules about its state does not need classes, and saying so with evidence is good design work.

The one-sentence version

Objects help when there is state with rules about it, because a type can hold both — and the rest of this course is learning to hold them well.

Terms you must now be able to define

Compile error · link error · runtime error · undefined behaviour · translation unit · namespace · abstraction · encapsulation · inheritance · polymorphism · object · class · invariant · value, reference and pointer — see the glossary.

If a term on that list is not yet something you can explain to somebody else, write it down as a re-test item. The course will use all of them again, and Module 4 uses invariant as its central idea.

Before you move on

• [ ] All warm-up and core exercises attempted, with the expected result checked
• [ ] Lab 1 builds with no warnings and passes its checklist
• [ ] The reflection is written, with numbers in it — lines changed, rules counted, functions affected
• [ ] At least one challenge problem attempted
• [ ] Quiz score ≥ 80%, and every miss explained in writing
• [ ] The skills checklist on the module page ticked with evidence

Further reading

• C++ Primer (5th ed.), chapters 1–2 — the most careful treatment of the language's basics at this level, including references and pointers.
• A Tour of C++ (3rd ed.), chapter 1 and the first section on classes — a working programmer's view of why types exist.
• cppreference.com — bookmark it now. You will use it for signatures, and for checking which standard version introduced a feature.
• The C++ Core Guidelines — read the introduction only. It explains the philosophy this course teaches, without the sixteen weeks of examples.

See Further Reading for editions and why these are the right ones.

---

Next: Module 2 — Classes and Objects. Module 2 turns the paper design from Challenge 1 into real, compiling classes — which is why Challenge 1 is worth doing properly, and why Lab 1's reflection is not busy-work.