Exercises — Modules (C++20) — concept and syntax

This is the primary module interface unit of module math. A module has exactly one such unit. Its exported names are the module's public face — the list on the box lid (the yellow line in the figure above). Why exactly one? The primary interface unit is the definition of the module's public surface; if two files both claimed to be it, the compiler would have two conflicting definitions of the same surface — so the language forbids it. Answer key: role = primary interface unit, count = 1.

• (a) module; — starts the global module fragment (the quarantine room for #include, defined in the box above).
• (b) export module math; — the primary interface unit.
• (c) module math; — an implementation unit (no export, adds no new public names).
• (d) export module math:geometry; — a partition interface unit (see Module Partitions).

• import math; → brings in only the exported surface (the lid's list, the yellow arrow in the figure). No pasting.
• #include "math.h" → textual copy-paste handled by The C++ Preprocessor.

export module strutil;
 
bool is_null(const char* s) {   // NO export => private to the module
    return s == nullptr;
}
 
export int length(const char* s) {   // exported => visible to importers
    if (is_null(s)) return 0;
    int n = 0;
    while (s[n] != '\0') ++n;
    return n;
}

Why this compiles and is correct: export module strutil; is the first real declaration, so this file is legally the primary interface unit. is_null has no export, so by the module rule it never crosses the box boundary — it is private to the module. length has export, so its name is placed on the lid. Crucially, length may still call is_null because both live inside the same module box; "private" only blocks outsiders, never fellow module members. So the code is both legal and does what the problem asked.

Rule broken: #include may not appear after the named-module region begins. #include must live in the global module fragment (the quarantine room), before export module ...;. Fixed:

module;                 // global module fragment starts
#include <cmath>        // legacy header allowed ONLY here
export module geometry;
 
export double norm(double a, double b) {
    return std::sqrt(a*a + b*b);
}

Why the fix is legal: module; opens the fragment; #include <cmath> now sits inside the only region that permits preprocessor includes; then export module geometry; begins the clean named region, after which exported declarations are allowed. Every line is now in the region the language requires for it.

Line B fails — seed was never exported, so it is invisible across the module boundary (the dashed red arrow in the figure). Why line A is legal: increment carries export, so its name is on the lid and import counter; places it in main's view. Line A therefore compiles and a = increment(5) = 6.

module account; marks account.cpp as an implementation unit of module account. Implementation units:

• share the module's internals (they can see everything the interface declared, so Account is a known type here), and
• cannot export new names — no export keyword is permitted at the module-declaration level here.

So the definitions of Account::Account and Account::balance are implementations of already-declared members, not new public names. The public face was fixed by the single interface unit. This keeps interface files small (fast to parse for importers) while heavy definitions recompile separately — the Build Systems and Compilation Speed win.

• #include (textual paste): the interface text is re-parsed in every translation unit, so the cost is 100 times 1, which is 100 units.
• compiled interface (parsed once, reused): parsed/compiled once into a binary interface, then reused, so the cost is 1 unit.

Speedup factor here is 100 divided by 1, which is 100 times. The general rule: for N importers, #include costs proportional to N, import costs proportional to 1 for that interface.

Why can't the compiler just cache the header work without modules? Each translation unit is compiled as an independent program run, and #include is pure text substitution done before the compiler even sees a "unit" — see Translation Units and Linkage and The C++ Preprocessor. The pasted header text can mean different things in different files, because macros defined before the #include line can change how the header parses. So the compiler is not allowed to assume the parse of <vector> in file A equals the parse in file B — it must redo it. A module interface removes that ambiguity: it is compiled in a fixed, self-contained context to a binary artifact, which is provably the same for every importer and therefore safely reusable. That provable sameness — not raw speed — is what unlocks the caching.

Legal order:

module;              // (1) opens the global module fragment
#include <cstdio>    // (2) legacy include — allowed only in the fragment
export module m;     // (3) begins the named-module region
export void f();     // (4) an exported declaration, after the region begins

Justification: #include is only legal in the global module fragment, which must come before export module m;; and exported declarations are only legal after export module m;.

Partition file (math-trig.ixx):

export module math:trig;
export double sine(double x);   // declared in this partition

Primary interface (math.ixx):

export module math;
export import :trig;   // re-export the partition so importers see its names

Why this is legal and works: export module math:trig; names a partition of math, not a new module — the colon syntax ties it to the parent module, so it is not a second primary interface (which would be illegal). The primary interface then writes export import :trig;, which both imports the partition and re-exports its names, placing them on math's own lid. Consequently a consumer writing import math; receives sine too. See Module Partitions. There is still exactly one primary interface unit; partitions are internal sub-units.

Global-fragment + interface (geometry.ixx):

module;
#include <cmath>            // quarantined legacy header
export module geometry;
 
export class Circle {
public:
    explicit Circle(double r);
    double area() const;    // declared here, defined in impl unit
private:
    double r_;              // private: hidden from callers
};

Implementation unit (geometry.cpp):

module geometry;            // no 'export' — adds no new public names
Circle::Circle(double r) : r_(r) {}
double Circle::area() const {
    return 3.141592653589793 * r_ * r_;
}

Consumer (main.cpp):

import geometry;
#include <iostream>
int main() {
    Circle c(2.0);
    std::cout << c.area();   // legal: area() is public and Circle exported
    // c.r_;                 // ERROR: r_ is private
}

Why each piece is legal: in geometry.ixx, the #include <cmath> sits in the global module fragment (the only place it is allowed), before export module geometry;; the class is exported so its name reaches importers. In geometry.cpp, module geometry; (no export) makes it an implementation unit that may define the already-declared members without adding new public names. In main.cpp, c.area() compiles because Circle was exported (module boundary crossed) and area() is public (class boundary crossed); c.r_ would fail because r_ is private — the class-access filter blocks it even though the module filter passed. Numeric answer: for Circle c(2.0), area() returns pi times 2 squared, which is 4 pi, approximately 12.566370614.

MAX does not resolve in main.cpp. Why: import deliberately does not carry macros across the module boundary — this is the exact leakage cure that modules were designed for (contrast the paste behaviour of The C++ Preprocessor). So MAX is unknown in main.cpp and that file fails to compile on the MAX token. The exported function is fine: cap is on the lid, so cap() = 100 is visible. Alternative that shares the macro: use a header unit (defined just above this level):

// put MAX in config.h, then in main.cpp:
import "config.h";   // header unit — DOES preserve macros

Why the alternative works: a header unit is still built from a header, so its #define MAX 256 survives into the importer, while it still enjoys the parse-once speed of a module. It is the one legitimate path to a shared macro under the module system.

• #include: 250 times 1, which is 250 parse-units.
• import: 1 parse-unit (compiled once, reused).
• Speedup ratio is 250 divided by 1, which is 250 times.

Why it collapses to one: as argued in L3.2, the module interface compiles to a single binary artifact that is provably identical for every importer, so the 250 re-parses that #include was forced into become a single reuse. This is the Translation Units and Linkage insight made quantitative: cost scales with how many times the same interface text is parsed, and modules collapse that to one.

Inside the module, total(20) = 20 - fee() - audit() = 20 - 5 - 3 = 12. Why total may call audit: they live in the same module box, and private only blocks outsiders — so this internal call is legal. In main: total(20) + fee() = 12 + 5 = 17. If you wrote total(20) + audit() in main, it would fail to compile — audit was never exported, so it is invisible across the module boundary (the dashed red arrow again). (The number would have been 12 + 3 = 15 if it compiled, but it does not.)

• How many primary interface units per module? → Exactly one.
• Where may #include legally sit inside a module? → The global module fragment (before export module).
• Does import (of a module) bring macros? → No — but a header unit does.
• Interface-parse cost scaling: #include vs import for N importers? → order N vs constant.
• What makes a file an implementation unit? → module Name; with no export.