Modules (C++20) — concept and syntax: Visual walkthrough

5.2.32 · D2 · Coding › C++ Programming › Modules (C++20) — concept and syntax

Hum sab kuch zero se banate hain. Koi bhi word use nahi hoga jab tak uski picture na dikha di jaaye.

Step 1 — Purani duniya: `#include` ek photocopier hai

KYA HAI. Hamare paas do source files hain, a.cpp aur b.cpp, dono #include "math.h" likh rahe hain.

PEHLE YEH KYUN DIKHAO? Taaki woh dard feel ho jis ke liye module system banaya gaya tha. Agar tum waste nahi dekhoge, toh import sirf ek bekaar naya syntax lagega.

PICTURE. Figure dekho. Ek header file math.h (mint page) dono files mein puri copy ho jaati hai (do lavender pages). Wahi text do baar parse hota hai — ek baar har .cpp ke liye. "Do baar" ko hundreds of files ke saath multiply karo jo hundreds of headers include karti hain aur tumhe wahi slow builds milenge jinki baat parent note ne ki thi.

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

Step 2 — "Parsing" ki cost kya hoti hai, aur repetition kyun hurt karti hai

KYA HAI. Hum count karte hain ki ek hi header text kitni baar parse hota hai.

YEH TOOL KYUN — COUNTING? Kyunki "modules faster hain" ek quantitative claim hai. Ise justify karne ke liye humein literally re-parses count karne padte hain. Yeh Build Systems and Compilation Speed argument ek number mein hai.

PICTURE. Bars parse-work dikhate hain. #include ke saath (coral bars) header ki parse cost har including file ke liye alag-alag appear hoti hai — teen files, teen full parses. import ke saath (mint bar) header ko ek baar parse kiya jaata hai, ek stored form mein compile kiya jaata hai, aur har importer bas woh stored form padhta hai.

Step 3 — Module banao: `export module math;`

KYA HAI. Hum primary interface unit likhte hain.

// math.ixx  — primary interface unit
export module math;   // <- is box ko "math" naam deta hai, ise front cover mark karta hai

Term by term:

export — "baharloge is box ke baare mein jaanna allowed hai."
module — woh keyword jo kehta hai box, ordinary file nahi.
math — box ka naam; importers baad mein import math; type karenge.

YEH STEP KYUN / YEH KEYWORD KYUN? Humein ek single unambiguous naam chahiye taaki compiler ek compiled interface store kar sake aur baad mein kisi bhi importer ko de sake. Ordinary files ka aisa koi handle nahi hota; isliye purane headers ko textual copying ki zaroorat padti thi. Ek naam copy ko replace karta hai.

PICTURE. Lavender box ka ek labelled front cover hai (export module math;). Abhi tak kuch bhi bahar nahi gaya — box sealed hai. Dekho yeh Namespaces in C++ se kaise alag hai: ek namespace sirf names group karta hai; ek module ek compilation boundary seal karta hai.

Step 4 — Box ke andar do tarah ke names

KYA HAI. Hum do functions add karte hain.

export module math;
 
export int add(int a, int b) { return a + b; }  // gate OPEN: bahar jaata hai
int secret_helper()          { return 42;      } // gate CLOSED: andar rehta hai

Exported line par term by term:

export — gate token; kisi declaration ke aage lagao aur woh naam box se bahar ja sakta hai.
int add(int a, int b) — woh naam jo export ho raha hai: ek function jo int return karta hai.
(koi export nahi) secret_helper par — koi token nahi, koi gate nahi, koi exit nahi.

KYUN. Yeh file level par encapsulation hai (parent note ka phrase). Box khud apni public surface decide karta hai. #include yeh kabhi nahi kar sakta tha — ek header sab kuch expose karta hai jo usme hota hai.

PICTURE. Green arrow (add) box wall ke gate se pass hota hai; coral naam (secret_helper) andar ki wall se bounce karta hai. Ek picture, export ka poora matlab.

Step 5 — Box ko sealed interface mein compile karo

KYA HAI. math.ixx → compiler → math ka compiled interface (sirf add hold karta hai). → ko "is compiled into" padho, bilkul jaise abhi define kiya.

YEH KYUN MATTER KARTA HAI. Yahi artifact Step 2 mein $r ≪ C$ ka pura reason hai. Ise padhna fast hai kyunki mushkil kaam (parsing, checking) ek baar pehle ho chuka hai. secret_helper isme nahi hai — seal gate par lagi thi.

PICTURE. Lavender source box ek compiler gear se flow karta hai ek chhote butter-coloured "sealed interface" tag mein. Notice karo ki secret_helper source side par chhoot gaya; sirf add tag tak pahuncha.

Step 6 — Import: seal padho, koi photocopy nahi

KYA HAI. Ek aur file module use karti hai.

// main.cpp
import math;                 // math ka sealed interface padho
#include <iostream>
 
int main() {
    std::cout << add(2, 3);  // OK: add exported tha  -> 5 print hoga
    // secret_helper();      // ERROR: gate cross nahi kiya kabhi
}

Term by term:

import math; — math naam ka box request karo; uske exported names (add) receive karo.
add(2, 3) — legal hai, add seal par hai; result hai $2 + 3 = 5$ .
secret_helper() — illegal hai, yahan invisible hai; compiler ne iske baare mein suna hi nahi.

KYUN. Step 1 se contrast karo: wahan poora header text aaya tha. Yahan sirf gate-approved surface aati hai, already compiled. Koi macro leakage nahi, koi order dependence nahi — kyunki koi text paste hi nahi ho raha.

PICTURE. Step 5 ka sealed tag main.cpp mein slide hota hai; sirf add visible hota hai (green), secret_helper greyed-out aur unreachable dikhta hai box wall ke peeche.

Step 7 — Edge case: `export module` ke baad `#include` (quarantine), aur header units

KYA HAI. Kahan #include allowed hai vs forbidden, aur modern alternative kya hai.

module;              // <- global module fragment SHURU HOTA HAI
#include <cmath>     // sirf yahan legal hai (quarantine zone)
export module geometry;   // named-module region shuru; is line ke baad koi #include nahi
 
export double hypot2(double a, double b) { return std::sqrt(a*a + b*b); }

IS PURI STEP KI ZAROORAT KYUN? Kyunki yeh sabse common beginner error hai (parent note ki pehli galti). Rule positional hai, isliye ise ek sentence se nahi, ek picture se samjhana padega. Legacy #include machinery The C++ Preprocessor hai; ise quarantine kiya jaata hai taaki uske macros sealed part mein leak na ho sakein.

Header-unit alternative (C++20). Kisi header ka text paste karne ki jagah tum header ko module-like unit ki tarah import kar sakte ho:

export module geometry;
import <cmath>;      // header UNIT: <cmath> ek baar compile hota hai, phir reuse hota hai

import <cmath>; — standard header <cmath> ko ek header unit ki tarah treat karo: ek baar parse karo, cache karo, phir sasta padho (real module ki tarah).
import math; ke unlike, ek header unit header ke macros ko carry karta hai — yeh deliberately legacy macro-dependent headers ke liye escape hatch hai.
Kyunki yeh ek import hai (nahi #include), yeh named-module region ke andar legal hai — ise quarantine ki zaroorat nahi. Sirf textual #include export module ke baad banned hai.

PICTURE. Ek red vertical line export module geometry; mark karti hai. Uske left (mint zone) #include allowed hai. Uske right (lavender zone) #include forbidden hai — ek red ✗ — lekin import <cmath>; (butter arrow) welcome hai, kyunki yeh import hai, paste nahi.

Step 8 — Ek module file ke chaar regions (private module fragment)

KYA HAI. Primary interface unit ka complete layout.

module;                       // (1) global module fragment  — #include yahan hota hai
#include <cmath>
 
export module geometry;       // (2) named-module region shuru hota hai
 
export double area(double r); // (3) purpose region — exported + private declarations
double helper(double x);      //     (private: koi export nahi)
 
module : private;             // (4) PRIVATE module fragment shuru hota hai
double helper(double x)       //     yahan ki definitions importers ko kabhi nahi dikhti
{ return x * x; }             //     AUR inhe change karne se importers ko rebuild nahi karna padta

Region by region:

(1) global module fragment — module; … export module tak. Sirf yahi jagah hai jahan textual #include ho sakta hai.
(2) named-module region — export module geometry; par start hota hai. Yahaan se #include banned hai (header units use karo).
(3) purpose region — tumhare exported aur private declarations; module ka substance.
(4) module : private; private module fragment open karta hai: ek tail zone jiske contents module ke bahar bilkul invisible hain. Iska special power: yahan code edit karne se importers invalidate nahi hote, toh unke builds trigger nahi hote.

YEH PURI STEP KYUN? Iske bina decomposition model mein ek missing quadrant hai. module : private; region (3) mein ek unexported declaration ke samaan nahi hai: dono importers ke liye private hain, lekin sirf private fragment guarantee karta hai ki usse change karne par importers rebuild nahi karenge.

PICTURE. Ek single file mein chaar stacked bands, top to bottom, har ek apne rule ke saath labelled; ek red ✗ #include tag pehle ke baad har band par hai.

Step 9 — Degenerate case: ek cover, kai pages, aur partitions

KYA HAI. Legal shapes, aur illegal waali.

File ke top par line	Role	Kitni allowed
`export module math;`	primary interface (front cover)	exactly ek
`module math;`	implementation unit (inside page)	kai
`export module math:geom;`	interface partition (named sub-section)	kai
ek doosra `export module math;`	—	illegal

ILLEGAL WAALI KYUN DIKHAO? Sabhi cases cover karne ka matlab hai ki kya toota hai woh bhi naam lo. Do front covers = box ki public face ki do definitions = ambiguity. Compiler ise reject karta hai.

PICTURE. Upar ek butter cover; neeche kai lavender inside pages; side mein ek mint "partition" tab clipped (same box, sub-labelled :geom); ek doosra cover faded draw kiya gaya hai red ✗ ke saath.

Ek-picture summary

Poori journey ek canvas par: ek source box (export module math;) jisme ek gate hai jo add ko bahar jaane deta hai aur secret_helper ko andar rokta hai → ek baar compile hoke ek sealed interface banta hai → import kiya jaata hai kisi bhi number of files ke dwara, har ek seal ko sasta padhke instead of re-parsing text. Left side par, quarantine room legacy textual #include ko confine karta hai; ek header unit (import <cmath>;) ise entirely bypass karta hai. (Yahan har → ka matlab hai "is compiled into", Step 5 ke according.)

Recall Feynman retelling — plain words mein bolo

Ek factory imagine karo jo ek perfect labelled crate banati hai. Crate ke andar parts hain; crate wall mein ek gate decide karta hai ki kaun se parts shipping label par dikhte hain (woh exported hain) aur kaun se hamesha andar bolted rehte hain (woh private hain). Factory is crate ko exactly ek baar banati aur inspect karti hai, phir ek chhoti sealed label print karti hai jisme sirf dikhne wale parts listed hain.

Jo bhi parts chahiye unhe poori factory ka photocopy nahi milta (yeh purana #include tarika tha — slow, aur wall par pinned har stray note bhi drag karta tha, yaani macros). Woh bas chhoti label padhte hain: import math;. Woh add use kar sakte hain, kyunki add label par hai; woh secret_helper nahi use kar sakte, kyunki woh kabhi crate se bahar nahi gaya.

Purani header machinery abhi bhi exist karti hai lekin saamne ek room mein locked hai — global module fragment, export module Name; se pehle. Tum wahan textual #include rakh sakte ho aur darwaze ke aage nahi; agar chahiye toh import <cmath>; header ko uski apni chhoti cached crate ki tarah treat karta hai aur darwaze ke baad allowed hai (aur yeh, uniquely, macros carry bhi karta hai). File ke bilkul peechhe ek private room hai, module : private;, jiske contents bahar koi kabhi nahi dekhta aur jiske edits importers ko kabhi rebuild nahi karte.

Har crate ka exactly ek label hota hai (ek primary interface); extra inside pages (module math;) bolts add karte hain lekin koi naya label entry nahi; extra labelled sub-sections partitions hain (export module math:geom;). Bas yahi poora idea hai, aur is page ka har figure us crate ki life ka ek frozen frame hai.

Recall Quick self-test

Photocopied header text ki jagah kya aata hai? → ek compiled (binary) module interface, ek baar padha jaata hai.
Sealed interface par kaun se names appear karte hain? → sirf exported waale.
Ek module mein textual #include akela kahan reh sakta hai? → global module fragment mein, export module se pehle.
Us border ke baad legacy header kaise use karein? → ise header unit ki tarah import karo, jaise import <cmath>;.
module : private; kya add karta hai? → ek private module fragment: importers ko invisible, aur ise edit karne se woh rebuild nahi hote.
Ek module mein kitne primary interface units hote hain? → exactly ek.

Prerequisites revisited: Translation Units and Linkage, The C++ Preprocessor, Namespaces in C++, Build Systems and Compilation Speed, Module Partitions. Parent: the Hinglish companion.