Chapter 11 — Teaching Notes
One-line purpose. Teach pointers thoroughly enough that students can read and fix any pointer code, and
teach the judgment to write almost none of it — the "prefer allocatable" rule and why it holds.
Key ideas to emphasize
=>vs=. This is the whole chapter in one distinction, and it is where beginners' bugs live. Drill it with the sticky-note metaphor (move the note vs write on the page) and thealias_vs_copytrace until students can predict every line. If they leave sure of nothing else, they must leave sure of this.- The two hazards, both silent. Undefined (never initialized →
associatedis UB) and dangling (freed target, still looks associated). Stress that neither announces itself — you cannot test your way out; you prevent them by habit (=> null()at birth;nullifyevery alias afterdeallocate). - Arrays usually win. The performance argument (pointer-chasing defeats prefetch + vectorization; one allocation per node) is the bridge to the whole book's thesis. Do not let "linked list" feel like the sophisticated choice — in Fortran it is the fallback.
- The rule, and why. Prefer
allocatable: automatic deallocation (safety), no aliasing (the compiler optimizes → connect to Ch. 27), deep-copy assignment. Pointers are for aliasing, links, polymorphism, callbacks, C interop — name the five. contiguousas a promise. It changes no results; it licenses optimization. Column contiguous, row strided. Foreshadow Ch. 29's use on a dummy argument.
Misconceptions to preempt
- "
p = are-pointsp." (No — that isp => a;=writes a value through an associatedp.) - "
associated(p)is always safe to call." (Not on an undefined pointer.) - "
deallocate(p)cleans upqtoo ifq => p." (No — it disassociates onlyp;qdangles.) - "Linked lists are the natural dynamic structure." (In Fortran, an
allocatablearray / index-based structure usually wins.) - "A pointer and an allocatable are interchangeable ways to get run-time memory." (Semantically very different: ownership, aliasing, cleanup, optimization.)
A live demonstration (7 minutes)
Type code/example-01-pointer-basics.f90 and run it, then make it fail: delete the => null() initializer
and show that associated(p) at the top is now meaningless (discuss why you cannot demo UB reliably — that
is the point). Then build the linked_list, and in destroy swap the two lines to deallocate(p); p =>
p%next; compile with -fcheck=all and, if available, run under valgrind to show the use-after-free. The
lesson lands harder from a tool's report than from a warning.
Class-time budget (~55 min)
- 12 min:
pointer/target,=>vs=, the sticky-note metaphor (§11.1). - 12 min: association status; undefined and dangling, with the fail-demo (§11.2).
- 10 min: linked list + safe teardown; why arrays usually win (§11.3).
- 12 min:
allocatablevspointer— the table and the rule; connect to Ch. 27 (§11.4). - 9 min: when you do need pointers;
contiguous/is_contiguous; the Project Checkpoint (§11.5).
Prerequisites to review
allocatable arrays and column-major order (Ch. 5); derived types and allocatable components (Ch. 9);
intent and assumed-shape (Ch. 6); modules and type-bound procedures (Ch. 8/9) for the case studies. A
five-minute recap of "why a local allocatable does not leak" (Ch. 5) primes the whole §11.4 argument.
Connections
Back: Ch. 1 (no-aliasing foreshadow), Ch. 5, Ch. 9. Forward: Ch. 13 (leaks/dangling via valgrind &
-fcheck=all), Ch. 14 (C interop, c_f_pointer), Ch. 27 (the no-aliasing advantage, in full), Ch. 29
(contiguous as an optimization lever). Naming these keeps the pointer material from feeling like a
dead-end corner.