noexcept specifier: Visual walkthrough — Hinglish deep dive

5.2.30 · D2 · Coding › C++ Programming › noexcept specifier

Yeh page parent noexcept idea ko bilkul scratch se, pictures ke saath rebuild karta hai. Hum ek completely empty box — memory ka ek tukda — se shuru karte hain aur step by step dekhte hain, kyun compiler aur std::vector ek single promise ki parwah karte hain. Har symbol use hone se pehle explain kiya gaya hai.

Step 1 — "An exception escaping" dikhta kya hai

KYA. Ek function bas ek room hai jisme aap enter karte ho, kuch kaam karte ho, aur bahar nikalte ho. Normally aap front door se nikalte ho (return). Ek exception ek alternate exit hai — ek trapdoor jo aapko side se bahar kheench leta hai, baki kaam skip karke.

PEHLE YEH KYUN DIKHAYEIN. noexcept ke baare mein sab kuch ek claim hai ki kaun se exits allowed hain. Jab tak hum do doors picture nahi kar sakte, promise ki baat nahi kar sakte.

PICTURE. Room ke bahar nikalne ke do raaste hain. Black arrow normal return hai. Red arrow exception trapdoor hai — woh cheez jo noexcept promise karta hai ki kabhi use nahi hogi.

Step 2 — Promise, ek sealed door ke roop mein drawn

KYA. Ek function ki signature ke baad noexcept likhna red trapdoor ko weld karke band kar deta hai. Aap compiler ko bol rahe ho: "is room mein sirf front door hai."

$the room void f () weld the trapdoor noexcept;$

void f() — function (room).
noexcept — specifier; yeh exception exit ko seal karta hai. Yeh exactly noexcept(true) hai.

KYUN. Jab compiler maan le ki trapdoor gone hai, toh woh cleanup scaffolding hata sakta hai jo woh otherwise room ke around banata hai sideways exit safely handle karne ke liye. Kam scaffolding = chhota, faster code. Woh saving hi promise karne ka poora reward hai.

PICTURE. Step 1 wala hi room, lekin ab red trapdoor bolted shut hai. Uske around scaffolding (dashed cleanup machinery) hata di gayi hai.

Step 3 — Promise todna: the terminate landmine

KYA. Maan lo aapne trapdoor seal kar diya (noexcept) lekin phir, room ke andar, aapne ek exception throw ki jo escape karne ki koshish karti hai. Exception ek aise exit ki taraf bhaagti hai jo ab exist hi nahi karti — cleanup scaffolding Step 2 mein delete ho gayi thi. Uske jaane ke liye koi jagah nahi hai.

KYUN. Runtime ek adhe-escaped exception ko bina unwinding information ke room mein ghumne nahi de sakta — yeh undefined chaos hai. Toh woh ek hi safe kaam karta hai: detonate kar deta hai.

$exception escapes a noexcept function ⟹ std::terminate()$

left side — tuta hua promise (ek real escape, caught nahi).
right side — std::terminate fire hoti hai: poora program foran mar jaata hai, is point ke upar destructors run hone ki koi guarantee nahi.

PICTURE. Exception (red) welded trapdoor se takraati hai. Kyunki escape route gone hai, impact std::terminate() trigger karta hai — program khatam ho jaata hai.

Step 4 — Promise se ek sawaal poochna: the `noexcept` operator

KYA. Yahi word ka ek doosra kaam bhi hai. noexcept(expr) ek sawaal hai jiska compiler compile time par jawab deta hai: "kya yeh expression guaranteed hai ki throw nahi karega?" Yeh ek bool return karta hai.

$noexcept(expr) = {true false expr can never escape expr might escape$

expr — code ka ek tukda, lekin yeh unevaluated hai (sizeof ki tarah): kuch actually run nahi hota.
result ek compile-time value hai, toh yeh constexpr mein feed ho sakta hai (dekhein constexpr).

KYUN. Hume generic code ke liye ek tarika chahiye ki woh kisi type T ko dekhe aur pooche "kya main tumhari operations par trust kar sakta hoon?" unhe run kiye bina. Operator woh inspection tool hai.

PICTURE. Ek magnifying glass (red) ek function ke upar hover karta hai aur uska door padhta hai: sealed → true jawab deta hai; open trapdoor → false jawab deta hai.

Step 5 — Woh scene jahan yeh pay off hota hai: ek `vector` ka room khatam ho jaata hai

KYA. Ek std::vector apne elements ko memory ke ek solid block mein rakhta hai. Jab woh fill ho jaata hai, toh use ek bada block grab karna hota hai aur har element ko transfer karna hota hai.

KYUN SET UP KAREIN. Yahi transfer ka moment hai jahan Step 2 ka promise machine ka decision badal deta hai. Danger dekhne ke liye pehle transfer dekhna zaroori hai.

PICTURE. Purana buffer (black, full) aur ek naya, bada buffer (black, empty). Elements ko purane se naye mein jaana hai. Flight mein element woh object hai jiske baare mein hum abhi parwah karne wale hain (red).

Step 6 — Danger: mid-transfer mein ek throwing move

KYA. Transfer ke liye, vector har element ko move kar sakta hai (uski guts steal kar le — cheap; dekhein Move semantics) ya copy kar sakta hai (duplicate — costly). Maan lo woh move karta hai aur, beech mein, ek move throw kar deta hai.

KYUN YEH DISASTER HAI. Ab kuch elements naye buffer mein hain, aur purane buffer ke originals move se pehle hi gutted ho gaye. Wapas koi clean state nahi hai — data aadha-aadha toot gaya. Yeh Strong exception guarantee tod deta hai (woh rule ki failed operation cheezein exactly waise hi chhod de jaisi thi).

PICTURE. Mid-transfer, element 3 ka move throw karta hai (red burst). Left buffer: gutted originals. Right buffer: kuch survivors. Dashed line corruption mark karti hai — wapas jaane ka koi raasta nahi.

Step 7 — Vector ka fix, promise se decide hota hai

KYA. Toh vector T ke move constructor ke baare mein Step-4 sawaal poochta hai:

$noexcept(T(std::move(x))) ⟶ {true false \Rightarrow move (fast) \Rightarrow copy (safe)$

T(std::move(x)) — x se move karke ek T construct karna.
operator T ke move constructor par promise return karta hai.
true → moving throw nahi kar sakta → originals gut karna safe hai → move.
false → ek move shayad mid-transfer throw kare (Step 6) → originals intact rakho → copy, aur originals ko sirf tab destroy karo jab saare copies succeed ho jaayein.

KYUN. Agar moving kabhi throw nahi kar sakta, toh Step-6 disaster impossible hai, isliye vector fearlessly fast lane leta hai. Agar throw ho sakta hai, toh vector safe khelta hai: copies originals ko untouched rakhte hain, toh ek thrown copy kuch nahi khoata. Yahi exact decision standard helper std::move_if_noexcept mein bottle ho jaata hai.

PICTURE. Raaste mein ek fork. Red signpost noexcept answer hai; true MOVE track par le jaata hai, false COPY track par.

Worked example Code mein payoff

struct Fast { Fast(Fast&&) noexcept; }; // sealed trapdoor -> vector MOVES
struct Slow { Slow(Slow&&); };          // open trapdoor   -> vector COPIES
 
constexpr bool a = noexcept(Fast(std::declval<Fast>())); // true
constexpr bool b = noexcept(Slow(std::declval<Slow>())); // false

Step 8 — Degenerate cases (taaki koi scenario surprise na kare)

KYA & KYUN. Corners jo fast/slow story ko bhi survive karni chahiye:

Empty vector (0 elements): reallocation kuch transfer nahi karti, toh move-vs-copy choice kabhi fire nahi hoti. Dono branches ek hi "kuch nahi" karte hain. Koi danger nahi, koi decision nahi.
Ek type jisme koi move constructor nahi (sirf copy): move ke baare mein noexcept(...) sawaal copying par fall back karta hai — wahi safe track jaise false.
Throw jo move ke andar catch ho jaaye: agar T ka move internally throw karta hai lekin use catch karke declared noexcept hai, toh operator true return karta hai — promise woh hai jo pada jaata hai, internals nahi. (Agar woh jhooth bolte hain aur escapes, toh Step 3 ka landmine fire karta hai.)
Ek noexcept(false) move jo actually kabhi throw nahi karta: phir bhi "might throw" padha jaata hai, toh vector copies karta hai. Promise, runtime behaviour nahi, choice drive karta hai — ek honest noexcept hi speed unlock karta hai.

PICTURE. Chaar chhote panels: empty box (koi transfer nahi), copy-only type, caught-inside, aur honest-but-unmarked type — har ek apne track par route kiya gaya, deciding label red mein.

Ek-picture summary

Ek diagram poori chain compress karta hai: trapdoor seal karo → compiler scaffolding hatata hai → operator seal read kar sakta hai → vector fast MOVE track leta hai. Seal todo aur wahi path std::terminate() tak le jaata hai.

Recall Feynman retelling — plain words mein poora walkthrough

Ek function ek room hai jisme do exits hain: normal door aur emergencies ke liye ek secret trapdoor (exceptions). noexcept bolna trapdoor ko weld karke band kar deta hai, aur kyunki builder trust karta hai ki koi trapdoor nahi hai, woh uske around se saari safety scaffolding hata deta hai — isliye aapka code lean aur faster ho jaata hai. Lekin agar koi emergency koshish kare sealed trapdoor use karne ki, toh bahar nikalne ka koi safe raasta nahi, toh building wahi dhaaye di jaati hai (std::terminate). Ab ek vector socho jo apna box se bada ho gaya aur har item ko ek bade box mein le jaana chahta hai. "Moving" se carry karna fast hai lekin jaate waqt purana box khali kar deta hai — agar beech mein kuch gir gaya, toh dono box barbad. Toh choose karne se pehle, vector har item ke move par seal read karta hai: sealed (noexcept true) matlab girna impossible hai, toh woh fearlessly aur fast move karta hai; unsealed matlab woh safe khelta hai aur copies karta hai, originals ko tab tak rakhta hai jab tak har copy land na ho jaaye. Ek honest promise, aur poori machine speed up ho jaati hai.