Mini Projects¶
Ten small projects, one idea each. They exist to close the gap between "I followed the lab" and "I can build it from nothing", because a project is what happens when nobody hands you the class names.
Each one is a few hours, one to three classes, and no persistence. Do them while you are working through the modules they name — they are sized to be finished in an evening, not over a weekend.
No complete solutions are provided. Each brief states what to build, the constraints, and the checklist you assess yourself against. That is deliberate: the brief is the job specification, and the checklist is the code review.
The ten projects¶
| # | Project | Difficulty | Effort | Modules | What it adds |
|---|---|---|---|---|---|
| 1 | Temperature Converter | Beginner | 2–3 h | 2, 4 | A class that owns an invariant, and const correctness |
| 2 | Saving Account | Beginner | 3 h | 4 | Encapsulation that actually prevents a wrong state |
| 3 | Fraction Type | Beginner | 3–4 h | 5 | Operator overloading with a normalised invariant |
| 4 | Visitor Counter | Beginner | 2 h | 5 | Static members as class-level state |
| 5 | Shape Areas | Intermediate | 4 h | 7 | A polymorphic container, and slicing avoided |
| 6 | Stopwatch | Intermediate | 3–4 h | 3, 10 | Lifetimes, and value semantics on a racy type |
| 7 | Playlist Slice | Intermediate | 4–5 h | 11 | Ownership with std::unique_ptr |
| 8 | Generic Ring Buffer | Intermediate | 4–5 h | 12 | A template container with a non-type parameter |
| 9 | Report Parser | Intermediate | 4 h | 13 | Failure as a value: a small exception hierarchy |
| 10 | Word Frequency | Intermediate | 4 h | 14 | Containers and algorithms instead of hand-written loops |
What every mini project requires¶
Stated once, identical in every brief:
- A header and a source file, not one
main.cpp. - One class per idea. If a class's responsibility takes "and" to describe, it is two classes.
- An enforced invariant, or a written explanation of why the type has none.
- No warnings with
g++ -std=c++17 -Wall -Wextra -Werror. - ASCII-only output, so the programs behave the same in every terminal.
- A test run recorded, not just "it seemed to work".
How to use a mini project¶
- Read the brief once, without a compiler open.
- Write the class declaration first — members, invariants, the operations you need.
- Make it build, then make it correct, then make it clean. In that order.
- Run the testing checklist honestly. A tick you cannot point at is not a tick.
- Only then read the brief's suggested design and compare it with yours.
The comparison is the point. If you disagree with the suggestions, write down why — a justified disagreement is a better outcome than agreement.
Related: All projects · Project roadmap · Intermediate projects · Labs