Ch14 Discussion

Discussion Guide

Warm-up (think–pair–share, 5 min). "You call a C function from Fortran, it compiles with no warnings, and it prints nonsense. Where do you look first?" (Target: the value attribute on scalars — the answer should become reflexive.)

Main discussion (15–20 min). 1. Why can't the compiler catch it? Put a value-vs-reference bug on the board and ask students to explain precisely why neither the Fortran nor the C compiler can flag it. Use this to teach that an interface is a contract between two translation units, and to justify always testing a new interface against a hand-computed result. 2. The transpose that never comes. Present a C driver filling a grid row-major and a Fortran kernel reading it column-major. Ask: what does the user see (a "rotated" result, no crash)? Then have the class design a layout contract that avoids any copy, and estimate (Ex.14.20) what a per-step transpose would cost on a 4000×4000 grid. 3. Library vs program. Pose CS-02's scenario: a C (or Python) team wants to drive your solver. Discuss what has to be designed at the boundary (the config struct, the layout contract, the string handling) to turn a Fortran program into a callable library — and why bind(c) on one entry point is enough.

Group activity (10 min). In pairs, hand each pair a short C header (3–4 prototypes mixing scalars, const pointers, and non-const pointers) and have them produce the Fortran interface module — deciding value vs by-reference and intent(in) vs intent(inout) for every argument from the const qualifier alone. Swap and critique. (This is CS-01 in miniature and is the single most transferable skill of the chapter.)

Exit ticket. "State the two silent-failure rules of C interop in one sentence each." (Expect: scalars from C need value or you pass an address as a value; a 2-D array is indexed oppositely by the two languages, so agree a layout contract rather than transpose.)