Skip to content

Quiz 9 — Answers

Back to the quiz

Q1 — B, aggregation. In aggregation the part exists independently and outlives the whole (a player outlives the team). In composition the part is owned by the whole and dies with it.

Q2 — True. That is the definition of composition: the part's lifetime is bounded by the whole's. It is usually modelled by holding the part by value.

Q3 — A, C. A playlist referring to songs in a shared library (A) and a team referring to independent players (C) are aggregation. A car and its engine (B) is composition — the engine is part of the car. A document and its own text buffer (D) is composition too.

Q4 —

make A
make B
ready
gone
drop B
drop A

Members are constructed in declaration order (first_, then second_) before the body, and destroyed in reverse order after it.

Q5 — The bug is a dangling pointer: checkIn stores the address of a member passed by reference, and if that member is a local (as in the module's session example), it is destroyed when the function returns — leaving present_ pointing at freed storage. list() then reads a destroyed object (undefined behaviour). The fix is an ownership decision: the reading room should observe, not own, and the members must outlive the room's use of them. Either the caller owns the members and keeps them alive for as long as the room does, or the room stores owning values (a std::vector<Member>), so their lifetime is the room's.

Q6 — Car and engine: composition. Doctor and appointment: composition if the clinic owns appointments (or association if appointments exist independently) — either is acceptable if justified. Course and lecturer: association — a lecturer exists independently and may teach elsewhere.

Q7 — A+ B+ O+ O- B- A-. Members are constructed in declaration order (a_, then b_) before the Owner body; destruction reverses it after the body: O-, then members in reverse declaration order (B-, then A-).

Q8 — To own another object means to be responsible for its lifetime: when the owner is destroyed, the owned object is destroyed too, and the owner may not outlive it (nor it the owner). It is a statement about who is responsible, not about which syntax is used.

Q9 — Student and Course outlive any registration, so a Registration associates with them (references or non-owning pointers). The registry composes its registrations — it owns them and destroys them when a course is cancelled. The capacity rule is enforced by the one operation that adds a registration (for example Course::enrol), which refuses when enrolled_ == capacity_.

Q10 — It cannot compile because neither type has a finite size. A Wife would contain a Husband, which contains a Wife, and so on — the compiler cannot lay out an object of infinite size. Break the cycle either by (1) a pointer or reference in one direction (plain association — neither owns the other), or (2) a smart pointer in one direction and a weak_ptr back (std::unique_ptr for the owner, std::weak_ptr/raw pointer for the other). The choice says which one owns the other.

Marking. One point per question (Q3 all-or-nothing). Then read Marking Yourself.