Debugging — 10 seeded hunts

stock["pencil"] insert-or-assigns: on a miss it inserts ("pencil", 0) and hands back a reference — the “lookup” grew the map to size 2 (the Lesson 2 §2 trap, in the wild). Safe asks: if (stock.count("pencil") > 0) or auto it = stock.find("pencil"); if (it != stock.end()). Rule: [] to write, count/find to ask.

set keeps unique keys — the three 7s collapsed to one (size 2: {7, 9}). The insertions “failed” silently by design, which is exactly the contract, not a bug in the code — the bug is the expectation. For repeats: multiset<int> (sorted, duplicates allowed) or a vector + count. The lesson: choose containers by the duplicate question before the data arrives (the Records module’s uniqueness invariant, library-enforced).

unordered_map iteration order is unspecified — hash-table order, not key order; expecting alphabetical output was the bug (Lesson 2 §3’s “never rely”). Fixes: switch to map<string,int> (sorted-by-key iteration, O(log n) updates), or keep the unordered speed and sort the keys into a vector<string> when presentation order is needed (pay once at output, not per update).

Each erase shifts the tail left, so the index that was about to be examined now names the next element — which gets skipped. Trace: erase 2 (index 1) → {1,3,4,5,6}; i=2 sees 4 → erase → {1,3,5,6}; i=3 sees 6 → erase → {1,3,5}. It “works” here by luck of the data — change the input and elements survive that shouldn’t (and the classic variant runs off the end entirely). Correct patterns: (1) the erase-remove idiom — v.erase(remove_if(v.begin(), v.end(), [](int x){ return x % 2 == 0; }), v.end()); (the library’s version of exactly this dance); (2) the manual iterator dance — for (auto it = v.begin(); it != v.end(); ) { if (*it % 2 == 0) it = v.erase(it); else ++it; } — the assignment re-validates the iterator, and ++ only on keep. Both encode the rule the hand loop violated: erase changes the structure; the walk must re-anchor.

Line B (at) throws std::out_of_range — catchable, named, located. Line A ([]) is unchecked — reading garbage or crashing, silently (the Pointers module’s raw-array honesty, kept for performance parity with C). The library offers both because the checked form has a price and hot loops may pay it deliberately. The course’s allocation of the pair: [] inside code that has already bounds-validated (loops bounded by size()); at at boundaries and with external data — the defensive-programming rule (validate at the door, trust inside) applied to the library’s own API.

push_back may have reallocated (capacity grew past its old block) — it points into freed memory; dereferencing is undefined behaviour (garbage, crash, or — worst — seemingly fine). The invalidating operation: any growth that reallocated (insert/erase likewise). Safe ordering: take iterators after the last structural change; if you must hold across mutations, re-take begin() after, or hold an index into a vector (indices survive; addresses don’t) — or choose list/set, whose iterators survive non-erasing changes (Lesson 3 §1’s stability table).

pop() returns void — deliberately. If it returned the top, the return would require a copy after removal, which cannot throw safely (the library’s exception-safety history — summarized honestly: separating peek from pop lets each operation guarantee what it does). The two-step: int top = s.top(); s.pop(); — test-then-use, the course’s standing rule in adapter clothing. (Forgetting empty() before top/pop is the companion bug — the guard clause lives here too.)

priority_queue puts the largest element on top by the comparator — and urgency < other.urgency declares higher number = larger, so urgency 2 outranks 1: “report” on top is the contract working against the intention. Cure 1: reverse the comparator — return urgency > other.urgency; (the “smallest on top” convention from E9). Cure 2: define urgency so bigger-is-more-urgent (score 1→3 scale) — fix the model, not the comparator, when the domain allows. Both cures encode the rule: the comparator defines “greatest”; priority_queue hands you the greatest — write the comparator for the top you want.

Prints a wrapped negative (or similar garbage) — the seed 0 made the accumulator an int, and 2.9 billion overflows int: signed overflow is undefined behaviour, silently accepted here. Fix: seed 0LL (long long total) — the seed’s type is the accumulator’s type. General rule: choose the seed for the arithmetic the whole sum needs, not the type of one element (the same rule that chose 0.0 for averages — the Foundations module’s conversion traps, resident in one parameter).

Line A — mutating lookup: marks[n] on “Zaid” (absent) inserts (“Zaid”, 0) — the membership test grows the map and, worse, prints “Zaid passed\n” never but “Zaid” now occupies memory with a 0 that later code may read as data; use find/count. (D1’s hunt, third appearance this module — it earns the repetition.) Line B — clean, deliberately: the structured-binding auto& mutation is legal and updates the map in place — the audit includes one clean line so the fix-list doesn’t become a reflex; the curve works. Lines C/D — the audit’s real lesson: marks["Zaid"] = 66 inserts a node; for map, insertion does not invalidate other iterators (node-based structure), and “Zaid” sorts last — so “first” survives here. But the same two lines against a vector (D6) or an unordered_map (no guarantee at all) would break — this is a latent bug: legal for map today, broken the day the container changes. Classify: A is a bug, B is clean, C/D is a contract dependency. Verdict order: mutating lookup → reference check → invalidation contract.