Modules (C++20) — concept and syntax: Question bank

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

Ye bank parent se liya hua vocabulary build karta hai: module unit, primary interface unit, implementation unit, global module fragment, aur export / import gates. Helpful prerequisites: The C++ Preprocessor, Translation Units and Linkage, Namespaces in C++, Build Systems and Compilation Speed, aur Module Partitions.

True or false — justify

Har line ko click karke reveal karo; answer side mein hamesha reason hota hai, sirf verdict nahi.

export module math; interface file mein kahin bhi aa sakta hai jab tak main se pehle aaye.

False — yeh pehli real declaration honi chahiye; sirf ek global module fragment (module; … #includes) aur comments hi iske pehle aa sakte hain.

Ek module aur ek namespace ek hi encapsulation mechanism ke do naam hain.

False — ek namespace names ko lookup ke liye group karta hai; ek module control karta hai kaun se names translation-unit boundary cross karte hain. Tum ek namespace export kar sakte ho, isliye dono compete nahi karte balki compose karte hain.

import math; tumhari file mein math ka code textually paste kar deta hai, bas faster.

False — import ek compiled binary interface se link karta hai; kuch bhi paste nahi hota. Yahi reason hai ki order aur macros ab leak nahi karte.

Ek module ke paas do files ho sakti hain jo dono export module math; se shuru hon.

False — exactly one primary interface unit allowed hai. Extra public files ko partitions hona chahiye jaise export module math:part;.

module math; (bina export ke) illegal hai kyunki har module file ko export chahiye.

False — yeh ek valid implementation unit hai; yeh module ke internals share karta hai lekin koi naye public names nahi add karta.

Ek class ko export mark karna uske saare members ko importers ke liye visible bana deta hai.

False — export module boundary cross karta hai, lekin private/protected class ke andar member access block karte rehte hain. Ye dono axes independent hain.

Kyunki modules macros leak nahi karte, tum ab files ke beech ek macro kabhi share nahi kar sakte.

False — ek header unit (import "config.h"; ya import <cassert>;) macros preserve karta hai; sirf named-module import unhe suppress karta hai.

import <iostream>; aur #include <iostream> identical build behaviour produce karte hain.

False — header unit build mein ek baar parse/cache hoti hai; #include har translation unit mein header text ko dobara parse karta hai (dekho Build Systems and Compilation Speed).

Include guards module interface unit ke andar abhi bhi required hain.

False — modules ek baar binary interface mein parse hote hain, isliye re-inclusion se double-definition ho hi nahi sakti; guards wahan pointless hain.

export { … } block ke andar export ka matlab hai ki har declaration ko bhi individually export mark karna hoga.

False — block already uske andar sab kuch export kar deta hai; har line par export repeat karna redundant hai, required nahi.

Spot the error

Har line flawed code ya reasoning describe karta hai; reveal exact fault aur fix batata hai.

export module m; phir agली line par #include <vector> — kya break hoga?

#include named-module region shuru hone ke baad forbidden hai; yeh global module fragment mein jaana chahiye (module; → includes → export module m;).

Ek implementation file export module account; likhti hai interface file se "match" karne ke liye — kya galat hai?

Implementation unit ko module account; hona chahiye bina export ke. Do export module account; files do primary interface units declare karengi, jo illegal hai.

Ek header ek normal, non-module .cpp ke bilkul upar module; likhta hai aur global module fragment expect karta hai — problem?

module; tabhi global module fragment shuru karta hai jab usi file mein uske baad export module …; aaye. Jo file kabhi module declare nahi karti, usmein yeh meaningless/ill-formed hai.

import math bina trailing semicolon ke likha — yeh directive ki tarah kaam kyun nahi karega?

import ek declaration hai, preprocessor line nahi; har C++ declaration ki tarah ise terminating ; chahiye. Isko miss karna syntax error hai, #include ke unlike jo line-based hai.

Ek caller import math; karta hai aur phir secret_helper() (un-exported function) call karta hai — kya hoga?

Compile error: secret_helper kabhi export nahi hua, isliye yeh module boundary ke paas invisible hai chahe math ke andar exist karta ho.

Koi .ixx interface file ko import karne ki jagah #include karta hai — kya galti hai?

Textual inclusion module-declaration syntax ko consumer mein raw text ke roop mein kheeench laata hai, compilation tod deta hai. Module interfaces import kiye jaate hain, include nahi.

Do partitions export module math:a; aur export module math:a; alag-alag files mein — clash kahan hai?

Partition names ek module ke andar unique hone chahiye; do files jo :a claim karti hain woh same partition interface unit ki redefinition hai.

Why questions

export aur public dono ka matlab hai "outsiders use kar sakte hain" — do keywords kyun rakhein?

Ye alag-alag axes par kaam karte hain: export decide karta hai kaun se file-level names module se bahar jaate hain; public decide karta hai kaun se class members callers touch kar sakte hain. Ek export ki hui class ka private member hidden rehta hai.

Standard named-module import se macros cross karna kyun forbid karta hai?

Un silent name/macro leakage ko khatam karne ke liye jo The C++ Preprocessor ko plague karta hai. Macros suppress karna ek deliberate feature hai jo import ko order-independent aur predictable banata hai.

Ek module ek baar kyun parse hota hai jabki ek header har translation unit mein dobara parse hota hai?

Module ka interface ek binary interface artifact mein compile hota hai jo compiler reuse karta hai; ek header plain text hai jo preprocessor har translation unit mein dobara paste aur parse karta hai.

export module Name; pehli real declaration kyun honi chahiye?

Iske baad ka sab kuch named module se belong karta hai. Agar ordinary declarations pehle aatein, toh compiler nahi bata sakta ke woh module ke part hain ya (unnamed) global module ke — isliye boundary pehle se fix honi chahiye.

Global module fragment exist hi kyun karta hai agar modules #include replace karte hain?

Ek quarantine zone ke roop mein: legacy code aur third-party headers abhi bhi #include use karte hain, isliye fragment tumhe unhe module ke clean, isolated interface ko pollute kiye bina pull in karne deta hai.

Ek module ko .ixx interface aur .cpp implementation mein split kyun karein?

Interface advertise karta hai kya exist karta hai; implementation hold karta hai kaise. Chhoti interface files ka matlab hai importers kam recompile karte hain, incremental builds speed up hoti hain.

Partitions bahut saare interface units banane se zyada preferred kyun hain?

Ek module exactly ek primary interface unit allow karta hai; partitions tumhe ek bade module ko files mein split karne dete hain jabki primary unit ke zariye assembled ek single, coherent public face present karte hain.

Edge cases

Agar kisi module ki primary interface unit kuch bhi export na kare toh kya hoga?

Bilkul legal hai — yeh ek empty public surface wala module define karta hai. Importers module name access kar lete hain lekin koi usable declarations nahi milti.

Kya global module fragment mein sirf #include nahi, ordinary code bhi ho sakta hai?

Yeh sirf preprocessor directives (mainly #include) ke liye intended hai; wahan normal definitions dalna ill-formed hai. Real code export module …; ke baad jaata hai.

Kya import ek function body ke andar appear ho sakta hai?

Nahi — import ek module-level declaration hai aur namespace/global scope par baithna chahiye, use hone se pehle, function ke andar nested nahi.

Ek module ke andar jo name na export hua ho aur na anonymous namespace mein ho, uska kya hota hai?

Uski module linkage hoti hai: usi module ke doosre units ko visible lekin importers ko nahi — fully private aur fully public ke beech ek middle ground.

Kya import std; C++20 mein exist karta hai?

Nahi — import std; ek C++23 feature hai. C++20 mein tum import <iostream>; jaise header units use karte ho module-like standard-library imports ke liye.

Agar do importers dono import math; karein, toh kya math do baar compile hoga?

Nahi — interface ek baar binary artifact mein build hota hai aur har importer ke saath share hota hai, jo headers ke comparison mein core speed advantage hai.

Kya ek implementation unit aisi modules import kar sakta hai jo interface ne nahi kiye?

Haan — ek implementation unit jo kuch bhi internally chahiye woh pull in kar sakta hai bina un imports ko module ke importers ke samne expose kiye, public interface ko minimal rakhta hai.

Recall Jaane se pehle ek-line self-audit

export vs public axis? → boundary-crossing vs class-member access.
Module mein #include ki ek hi jagah? → global module fragment.
import std; availability? → C++23, C++20 nahi.
Module mein primary interface units kitne? → exactly one; baaki partitions hain.