Compile-time assertions — static_assert: Visual walkthrough

5.1.31 · D2 · Coding › C Programming › Compile-time assertions — static_assert

Hum ek guiding phrase ke saath poore raste chalte hain:

"Agar sach program run hone se pehle hi fix hai, toh abhi check karo — ek aise gate se jo kuch cost nahi karta."

Step 1 — Do alag clocks: build time vs run time

KYA. Kisi bhi code se pehle, hum program ki life ke do moments alag karte hain jinhein beginners often milaa dete hain:

Compile time (a.k.a. translation time): jab compiler naam ka program tumhara text file padhta hai aur use machine-code file mein badalta hai. Tumhara program tab tak exist hi nahi karta.
Run time: baad mein, jab koi us machine-code file ko double-click karta hai aur woh actually kaam karta hai.

KYO. Ek static_assert poori tarah se pehle moment mein rehta hai. Agar tumhein in do clocks ke beech ka gap feel nahi hota, kuch bhi samajh nahi aayega — tum expect karte rahoge ki woh "run" karega.

PICTURE. Figure mein, ek timeline hai. Compiler ki window left mein hai; program ki life right mein hai. Red marker woh ek hi instant dikhata hai jab static_assert alive hota hai — program boot hone se bhi pehle.

Figure — Compile-time assertions — static_assert

Step 2 — "Constant expression" kya hota hai (fuel)

KYA. Ek constant expression koi bhi aisi calculation hai jiska value compiler khud nikaal sakta hai, sirf source mein fixed cheezein use karke: number literals, sizeof(...) ke results, enum values, aur #defined constants. Koi variables nahi jo baad mein fill karo, koi function calls nahi.

KYO. Jo gate hum bana rahe hain woh sirf kisi aisi cheez par swing kar sakta hai jo compiler ko pehle se pata ho. Ek door aisi visitor ke basis par open nahi kar sakta jo abhi aayi hi nahi. Toh sabse pehli requirement yeh hai: condition abhi jaanna zaroori hai.

PICTURE. Do bins hain. Left mein (red = accha fuel jo hum use kar sakte hain): sizeof(int), enum COLOR_COUNT, 1024. Right mein (rejected): n jo keyboard se padha gaya, get_count(). Ek arrow dikhata hai ki sirf left bin static_assert mein flow kar sakta hai.

Is jaane-pehchane value ko $v$ kehte hain. Neeche sab kuch iske baare mein hai ki compiler $v$ ke saath kya karta hai.

Step 3 — Compiler $v$ evaluate karta hai (arithmetic, execution nahi)

KYA. Compiler tumhara constant expression $E$ leta hai aur uski ek single value $v$ compute karta hai. Jaise: $= 4 is machine par sizeof(int) compare karta hai == literal 4$ compiler pehle se jaanta hai ki sizeof(int) yahan 4 hai, 4 == 4 compare karta hai, aur $v = 1$ (true) milta hai.

KYO. Log assume karte hain "arithmetic hai, toh zaroor run hoga." Nahi — arithmetic compiler khud paper par karta hai, translation ke dauran. Finished program kabhi yeh sum dekhta hi nahi.

PICTURE. Ek chhota "compiler calculator" box. Expression sizeof(int) == 4 andar jaata hai; single number 1 (red) bahar aata hai. Output tape ka label $v$ hai.

Step 4 — Gate: do doors jo decide hoti hain $v$ zero hai ya nahi

KYA. Ab woh rule jo static_assert ko define karta hai. Number $v$ ek fork par pahunchta hai:

compile (E) = {success, kuch emit nahi error: message print karo, stop v \neq = 0 (true) v = 0 (false)

Term by term: $v \neq = 0$ pass door hai — build continue hoti hai aur koi code add nahi hota. $v = 0$ fail door hai — compiler tumhara "message" print karta hai aur ruk jaata hai.

KYO. Hum ek fail-fast at build time guard chahte hain. Ek gate jo "kya $v$ zero hai?" par swing kare woh exactly ek truth-gate hai: false sab kuch rok deta hai, true invisible hota hai. Dhyan do ki woh koi bhi non-zero value ko pass maanta hai (toh 2, -1, 1024 sab pass hote hain) — sirf special value 0 hai.

PICTURE. Number $v$ ek fork ki taraf chalta hai. Upper door (black, "PASS") build stream ko bina chuye jaane deta hai. Lower door (red, "FAIL") emergency stop hai jo message print karta hai.

Step 5 — Pass case koi footprint nahi chhodta

KYA. Jab $v \neq = 0$ hota hai, compiler assertion ke liye zero machine instructions emit karta hai. Jaise tumne wahan kuch likha hi nahi.

KYO. Yahi runtime check ke mukable poora fayda hai. assert(sizeof(int)==4) ek runtime comparison binary mein bake kar deta aur har run par check karta — waste hai, kyunki answer kabhi change nahi ho sakta. static_assert check ek baar, build par karta hai, phir gayab ho jaata hai.

PICTURE. Do binaries side by side. Left: source ke saath ek passing static_assert. Right: source bina uske. Compiled machine code (red bytes) identical hai — assertion ne koi trace nahi chhooda.

Recall "Zero runtime cost" kyun matter karta hai

Ek passing static_assert final binary mein kya add karta hai? ::: Kuch nahi — woh koi machine code emit nahi karta, toh binary byte-for-byte wahi hoti hai jaise woh wahan tha hi nahi.

Step 6 — Fail case: ek real worked example jo build rok deta hai

KYA. Parent se Worked Example 2 lo — ek array aur count ko sync mein rakhna:

enum { COLOR_COUNT = 3 };
const char *names[] = { "red", "green", "blue", "cyan" };  // oops, ab 4 hain
static_assert(sizeof(names)/sizeof(names[0]) == COLOR_COUNT, "out of sync");

Compiler compute karta hai $sizeof(names) / sizeof(names[0]) = 4$ , 4 == 3 compare karta hai, $v = 0$ milta hai → FAIL door → out of sync print karta hai aur build refuse kar deta hai.

KYO. Yeh dikhata hai ki gate ek silent logic bug (kisi ne colour add kiya, count bhool gaya) ko pakad leta hai aur use loud compile error mein badal deta hai — har jagah, hamesha, ship karne se pehle.

PICTURE. Division: sizeof(names) = 4 pointers × 8 bytes = 32, sizeof(names[0]) = 8 se divide, 4 (red) milta hai. Phir 4 == 3 → 0 → FAIL door bang se band.

Step 7 — Edge cases: woh doors jo tum expect nahi karte

KYA. Chaar corner situations, har ek gate par clearly land karti hain:

Condition likhi gayi	$v$	Door
`static_assert(1, "...")`	$1$	PASS (trivially true)
`static_assert(0, "...")`	$0$	FAIL (hamesha build rok deta hai)
`static_assert(-1, "...")`	$- 1 \neq = 0$	PASS (negative non-zero hai!)
`static_assert(sizeof(int) == 2, "...")` 32-bit par	$0$	FAIL

KYO. Yeh degenerate inputs hain jo beginners ko trip karti hain. 0 ek hard stop hai jo tum kabhi kabhi chahte ho (deliberately ek code path disable karne ke liye). -1 surprise karta hai — lekin rule sirf "kya yeh zero hai?" hai, aur $- 1$ zero nahi hai, toh woh pass hota hai.

PICTURE. Ek number line. $0$ ke single point (FAIL) ko chhodkar (saari shaded red = PASS region) sab kuch through flow karta hai; sirf woh akela black dot $0$ par FAIL mein girta hai.

Common mistake "Ek variable ise runtime check bana deta hai."

int n = get_count();
static_assert(n == 4, "...");   // compile hi nahi hoga

n ek run-time value hai, toh n == 4 constant expression nahi hai — gate test karne ke liye koi $v$ nahi hai. Fix: variables ke liye plain `assert` use karo; static_assert constants ke liye reserve karo. (Historical note: static_assert spelling ko C11/C17 mein `<assert.h>` chahiye hota hai lekin C23 mein yeh ek keyword hai.)

Ek-picture summary

Upar sab kuch ek pipeline hai: source text → compiler constant expression nikalti hai → use single number $v$ mein reduce karta hai → number do-door gate se milta hai → pass (invisible, koi code nahi) ya fail (message + stop).

Recall Feynman retelling — poora walkthrough simple shabdon mein

Ek bouncer imagine karo ek aisi building ke door par jo abhi bani hi nahi — woh compiler hai, jo tumhara program exist karne se pehle kaam karta hai (Step 1). Bouncer sirf woh facts andar aane deta hai jo woh khud check kar sake: box sizes, fixed numbers, enum values — kabhi nahi aisi koi guest jo baad mein aaye (Step 2). Woh apne dimag mein ek chhote calculator par arithmetic karta hai aur ek number likhta hai, $v$ (Step 3). Phir number do doors ka samna karta hai: agar woh zero ke alaawa kuch bhi ho, door silently khul jaata hai aur construction jaari rehti hai jaise check kabhi hua hi nahi (Steps 4–5). Agar woh exactly zero ho, alarm bajta hai — tumhara message print hota hai — aur poori building cancel ho jaati hai (Steps 4, 6). Magic yeh hai ki passing check finished building mein koi trace nahi chhodta (Step 5), aur sirf ek hi value hai jo tumhe rokti hai woh hai plain 0 (Step 7). Bas yahi hai static_assert: ek sach jo build-time clock par check hota hai, ek gate jo zero par swing karta hai, aur ek guard jo kaam ho jaane ke baad kuch cost nahi karta.

Active recall

Jab compiler condition ko ek value mein reduce karta hai, kaunsi value FAIL door trip karti hai?

Exactly zero; har non-zero value pass hoti hai.

Kya static_assert(-1, "msg") pass hoga ya fail?

Pass hoga, kyunki

- 1

non-zero hai.

Ek passing static_assert final binary mein kya add karta hai?

Kuch nahi — zero machine code.

Runtime variable condition mein kyun nahi ja sakta?

Woh constant expression nahi hai, toh compiler compile time par

v

compute nahi kar sakta.