noexcept specifier: Exercises — Hinglish deep dive

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

Poore page mein, yaad rakho woh ek contract jisse hum sab kuch derive karte hain: koi bhi exception ek noexcept function se escape nahi kar sakti — isko todo aur runtime std::terminate call kar lega.

Definition Do words jinhein hum poore page par use karte hain

Shuru karne se pehle, do roles ko clearly samajh lo jo same keyword play karta hai (parent note inhe highlight karta hai; yahan plain-words version hai):

Specifier — ek label jo function ki signature ke baad lagaya jaata hai jo us function ki ek property batata hai. void f() noexcept; — yahan noexcept ek specifier hai: yeh promise karta hai "f exception escape nahi hone dega." Yeh f ke run karne ke tarike mein kuch nahi badalta; yeh ek declaration hai jis par compiler aur callers trust kar sakte hain.
Operator — ek cheez jo tum kisi expression par apply karte ho ek value compute karne ke liye. noexcept(expr) ek operator hai: yeh expr ko dekhta hai aur compile-time bool produce karta hai — true agar expr throw nahi kar sakta, warna false. Sabse zaroori baat yeh hai ki expression unevaluated hota hai (sizeof ki tarah): operator isse inspect karta hai bina kabhi run kiye.
Same keyword, do kaam. Ek function head ke baad → specifier (ek promise). Kisi expression ke andar → operator (ek bool). Hum dono roles ko neeche test karenge.

Level 1 — Recognition

Goal: ek declaration padho aur batao yeh kya promise karta hai. Abhi koi reasoning chains nahi.

Worked example L1.1 — Promise padho

Har line ke liye jawab do: kya function throw nahi karne ka promise karta hai (true), ya kya use throw karne ki permission hai (false)?

void a() noexcept;          // (i)
void b() noexcept(true);    // (ii)
void c() noexcept(false);   // (iii)
void d();                   // (iv)

Recall Solution L1.1

(i) true — akela noexcept matlab noexcept(true) hota hai. (ii) true — explicit noexcept(true). (iii) false — noexcept(false) explicitly kehta hai "may throw". (iv) false — ordinary function ka default may-throw hota hai, yani noexcept(false).

Picture karo: noexcept function par ek stamp hai. Sirf (i) aur (ii) par "sealed, no leaks" wala stamp hai.

Worked example L1.2 — Specifier hai ya operator?

Page ke upar define ki gayi do roles use karke decide karo: har snippet mein, kya noexcept specifier ki tarah act kar raha hai (ek promise jo signature ke baad lagaya gaya hai) ya operator ki tarah (ek bool return karta hai)?

void f() noexcept;                    // (i)
constexpr bool x = noexcept(f());     // (ii)
void g() noexcept( noexcept(f()) );   // (iii)

Recall Solution L1.2

(i) Specifier — yeh signature void f() ke baad aata hai; yeh ek promise hai. (ii) Operator — noexcept(f()) ek expression mein baitha hai aur ek bool produce karta hai. (iii) Dono. Outer noexcept( ... ) specifier hai (follows void g()); inner noexcept(f()) operator hai jo woh bool compute karta hai jo ise fill karta hai.

Rule of thumb: function head ke baad → specifier; expression ke andar → operator.

Level 2 — Application

Goal: real expressions par noexcept operator evaluate karo.

Worked example L2.1 — Operator evaluate karo

Given:

int safe() noexcept { return 42; }
int risky() { throw 1; }

Har constexpr bool ki value kya hai?

constexpr bool p = noexcept(safe());          // (i)
constexpr bool q = noexcept(risky());         // (ii)
constexpr bool r = noexcept(safe() + safe()); // (iii)
constexpr bool s = noexcept(safe() + risky());// (iv)

Recall Solution L2.1

Operator poochta hai: "kya is expression mein har operation known non-throwing hai?" Yaad karo expr unevaluated hai — kuch bhi run nahi hota.

(i) true — safe par noexcept ka stamp hai.
(ii) false — risky koi promise nahi karta, isliye operator assume karta hai ki yeh throw kar sakta hai.
(iii) true — dono calls noexcept hain, aur int + int throw nahi kar sakta.
(iv) false — ek throwing operation (risky()) poore expression ko poison kar deti hai. Yeh saari sub-operations par ek AND hai.

Worked example L2.2 — Terminate ka landmine

void liar() noexcept { throw std::runtime_error("oops"); }
 
int main() {
    try { liar(); }
    catch (const std::exception&) { std::puts("caught!"); }
}

Kya "caught!" kabhi print hoga? Kya hota hai?

Recall Solution L2.2

Nahi, kabhi print nahi hoga. liar ne noexcept promise kiya, phir ek exception ko escape hone diya. Jis moment exception liar se bahar nikalne ki koshish karta hai, runtime std::terminate call kar leta hai — main ke try/catch tak control wapas jaane se pehle.

catch ek toote hue promise ke downstream mein hai, isliye is throw ke liye woh unreachable hai. Program abort ho jaata hai. Exception handling in C++ se compare karo jahan bina noexcept waali function exception ko us catch mein unwind hone deti.

Level 3 — Analysis

Goal: trace karo kyun contract toot raha hai (ya nahi) aur consequence predict karo.

Worked example L3.1 — Escape vs. contained

Har body ke liye, kya function call hone par terminate trigger hota hai?

void A() noexcept { throw 1; }                              // (i)
void B() noexcept { try { throw 1; } catch(...) {} }        // (ii)
void C() noexcept { try { throw 1; } catch(int) { throw; } }// (iii)
void D() noexcept { if (false) throw 1; }                   // (iv)

Recall Solution L3.1

Ek hi sawaal matter karta hai: kya koi exception function boundary cross karta hai?

(i) terminate — throw directly escape ho jaata hai.
(ii) fine — throw andar hi catch bhi ho jaata hai; kuch escape nahi hota. noexcept promise escape ke baare mein hai, sirf throw ki presence ke baare mein nahi.
(iii) terminate — catch(int) bare throw; se re-throw karta hai, aur woh re-thrown exception ab escape ho jaata hai.
(iv) fine — if (false) kabhi nahi liya jaata; koi exception kabhi produce nahi hoti, isliye kuch escape nahi hota. (Promise runtime behaviour ke baare mein hai; ek throw jo kabhi run nahi hota, kabhi isse nahi toodta.)

Worked example L3.2 — Destructor autopsy

struct S {
    ~S() { throw std::runtime_error("bye"); }  // kya yeh compile hoga? runtime par kya?
};
void use() { S s; }  // s scope ke end par destroy hoti hai

Kya destructor implicitly kuch promise karta hai? Runtime par kya hota hai?

Recall Solution L3.2

C++11 se, Destructors implicitly noexcept hote hain (yani ~S() noexcept chahe tumne likha na ho). Toh is destructor ne secretly contract sign kar liya — aur phir throw karta hai.

Runtime result: jab use() ke end mein s destroy hoti hai, throw ek implicitly-noexcept function se escape karta hai → std::terminate.

Language ne yeh kyun force kiya: agar ek destructor throw karta jab stack pehle se kisi doosri exception se unwind ho raha hota, toh do exceptions ek saath in-flight hote — undefined chaos. Throwing destructors ko ban karna (implicit noexcept ke zariye) us hole ko band karta hai.

Level 4 — Synthesis

Goal: noexcept ko move semantics aur containers ke saath combine karo performance explain karne ke liye.

Worked example L4.1 —

std::vector move ya copy kyun choose karta hai

struct Fast { Fast(Fast&&) noexcept; Fast(const Fast&); };
struct Slow { Slow(Slow&&);          Slow(const Slow&); };
 
std::vector<Fast> vf; /* ... push_back until it reallocates ... */
std::vector<Slow> vs; /* ... push_back until it reallocates ... */

Jab har vector reallocate karta hai (bade buffer mein grow karta hai), kya woh existing elements ko move karta hai ya copy? Strong exception guarantee ke zariye explain karo.

Recall Solution L4.1

Neeche ki figure do rows dikhati hai; yahan woh hai jo yeh words mein depict karti hai taaki tum image ke bina follow kar sako.

Top row (Fast, teal): "old buffer" mein left side par char teal boxes 0 1 2 3; move label waala orange arrow right side par "new buffer" mein char teal boxes ki taraf point karta hai. Kyunki Fast ka move constructor noexcept hai, moving kabhi throw nahi kar sakta, isliye vector safely har element ko move karta hai (cheap — bas ownership steal karta hai; dekho Move semantics).

Bottom row (Slow, plum): left mein "old buffer (kept intact)" mein char filled plum boxes; right mein "new buffer (copies)" mein char empty outlined boxes ki taraf plum arrow copy label ke saath point karta hai — outlines signal karte hain ki originals gutted nahi hue, duplicate hue hain. Ek caption padhta hai: agar koi Slow copy throws, originals untouched → strong guarantee held.

Reallocation par std::vector ko apne N existing elements purane buffer se naye mein transfer karne hote hain, aur woh Strong exception guarantee chahta hai: agar kuch bhi throw kare, vector exactly waise hi rhe jaise pehle tha.

Fast: iska move constructor noexcept hai, isliye moving mid-transfer kabhi throw nahi kar sakta. Vector saare elements move karta hai.
Slow: iska move throw kar sakta hai, isliye vector iske bajaaye copy karta hai. Copying har original ko untouched chhodti hai.

Critical edge case — "copy" exactly kaise rollback karta hai. Maano vector N elements copy kar raha hai aur element k ki copy throw karti hai:

Naye buffer mein already likhی gayi k−1 copies ko cleanup karna hoga. Vector un partially-constructed naye elements ko destroy karta hai (unke Destructors run karke — jo noexcept hain, isliye cleanup khud throw nahi kar sakta).
Woh naye buffer ka raw storage free karta hai.
Old buffer abhi bhi fully intact hai (copy isse read karta hai, kabhi modify nahi karta), isliye vector simply use karna jaari rakhta hai aur exception caller ko re-throw karta hai. Result: vector bilkul waise dikhta hai jaise reallocation attempt se pehle tha — strong guarantee.

Move yeh rollback kyun nahi kar sakta. Agar vector ne iske bajaaye move kiya hota aur element k ka move throw karta, toh pehle k−1 originals already gutted hain (unka content chura liya gaya hai). Unhe wapas move karna phir throw kar sakta hai, aur koi untouched source bacha nahi. Koi safe rollback nahi hai — yahi reason hai ki vector tabhi move karne ki himmat karta hai jab move noexcept ho. Yahi std::move_if_noexcept decide karta hai: move karo agar move noexcept hai, warna copy karo.

Worked example L4.2 — Generic swap ke liye conditional noexcept

Specifier complete karo taaki mySwap no-throw exactly tab promise kare jab T ko move karna throw nahi kar sakta:

template<class T>
void mySwap(T& a, T& b) noexcept( /* ??? */ )
{
    T tmp = std::move(a);
    a = std::move(b);
    b = std::move(tmp);
}

Recall Solution L4.2

template<class T>
void mySwap(T& a, T& b)
    noexcept( noexcept(T(std::move(a))) &&    // move-construct can't throw
              noexcept(a = std::move(b)) )     // move-assign can't throw
{
    T tmp = std::move(a);
    a = std::move(b);
    b = std::move(tmp);
}

Ise padhna: outer noexcept(...) specifier hai (promise); do inner noexcept(...) operators hain jo bools produce karte hain. && demand karta hai ki move-construction aur move-assignment dono non-throwing hon. Agar koi bhi throw kar sakta, toh poora promise false ho jaata hai — honest, koi landmine nahi. Body exactly wahi do operations use karti hai, isliye promise exactly reality se match karta hai.

Level 5 — Mastery

Goal: edges par design karo aur reason karo — propagation, type identity, overload resolution, aur subtle escapes.

Worked example L5.1 — Operator ko calls ke through compose karo

int base() noexcept { return 1; }
int mid()  noexcept(noexcept(base())) { return base(); }   // (i) kya promise?
int top()  noexcept(noexcept(mid()))  { return mid();  }    // (ii) kya promise?
constexpr bool result = noexcept(top());                    // (iii) value?

Har function ka final promise nikalo, aur final bool kya hoga.

Recall Solution L5.1

(i) noexcept(base()) true hai (base par noexcept stamp hai), isliye mid noexcept(true) hai.
(ii) noexcept(mid()) ab true hai (mid noexcept(true) par resolve hua), isliye top noexcept(true) hai.
(iii) noexcept(top()) isliye true hai.

Promise propagate hota hai: kyunki leaf base non-throwing hai, poori chain true inherit karti hai. base ko may-throw mein flip karo aur uske upar har conditional false mein collapse ho jaata hai — property operator ke through upar flow karti hai.

Worked example L5.2 —

noexcept C++17 se function type ka part hai C++17 se, noexcept function ki type ka part hai, sirf ek decoration nahi. Iske sharp consequences hain. Har ka jawab do:

void plain();
void nothrow() noexcept;
 
// (a) Kya plain ka pointer nothrow ka address hold kar sakta hai?
void (*p1)()          = &nothrow;   // legal?
// (b) Kya noexcept promise wala pointer plain ka address hold kar sakta hai?
void (*p2)() noexcept = &plain;     // legal?
// (c) Sirf noexcept mein differ karne wale do overloads:
void h(void (*)());          // overload A
void h(void (*)() noexcept); // overload B
// h(&nothrow) kaun sa overload select karta hai?

Recall Solution L5.2

Guiding rule: noexcept promise ko narrow karta hai, isliye conversions sirf "safe" direction mein allowed hain — ek stronger promise weak ki jagah kaam kar sakta hai, kabhi ulta nahi.

(a) Legal. nothrow zyada promise karta hai (kabhi throw nahi) than a plain function pointer require karta hai (may throw). Jahan may-throw expect ho, wahan no-throw function dena safe hai — tum over-delivering kar rahe ho. Ek void(*)() noexcept void(*)() mein implicitly convert hota hai.
(b) Illegal — compile error. p2 promise karta hai ki iska target noexcept hai, lekin plain aisa koi promise nahi karta. &plain wahan store karna type system ki nazar mein ek silent lie hogi jo woh refuse karta hai. void(*)() se void(*)() noexcept mein koi conversion nahi hai.
(c) Overload B select hota hai (void(*)() noexcept). &nothrow ki type void(*)() noexcept hai, jo B se exactly match karta hai (koi conversion nahi), jabki A se sirf noexcept→may-throw conversion ke baad match karta hai. Exact match conversion ko beat karta hai, isliye overload resolution B pick karta hai.

Big picture: kyunki noexcept type ka part hai, void() aur void() noexcept distinct types hain. Isliye generic code (jaise std::function, callback tables, ya template dispatch) kisi callable ki noexcept-ness par branch kar sakta hai — information type mein survive karti hai, sirf comment mein nahi.

Worked example L5.3 —

noexcept aur constexpr saath mein

constexpr int square(int n) noexcept { return n * n; }

(a) Kya constexpr aur noexcept independent promises hain? (b) Yahan har ek kya deta hai?

Recall Solution L5.3

(a) Haan, independent. Yeh alag sawaalon ke jawab dete hain:

constexpr ka sawaal: "kya yeh compile time par run ho sakta hai?"
noexcept ka sawaal: "kya yeh runtime par throw kar sakta hai?"

Tumhare paas dono mein se koi ek, dono, ya koi nahi ho sakta. Yahan square ke paas dono hain.

(b)

constexpr square(5) ko compilation ke dauran 25 mein fold karne deta hai (array sizes, template args, etc. mein usable).
noexcept callers ko noexcept(square(5)) == true query karne deta hai aur compiler ko iske liye exception-cleanup machinery skip karne deta hai.

Yeh orthogonal tools hain jo same signature mein baithte hain.

Worked example L5.4 — Ek "logging guard" destructor design karo

Tum chahte ho ek RAII type jiska destructor ek log line likhta hai, aur logging throw kar sakta hai (maan lo disk full hai). Destructor kaise likho taaki logging failure program crash nahi kar sake?

struct Guard {
    ~Guard() /* implicitly noexcept! */ { logAppend("closed"); /* may throw */ }
};

Recall Solution L5.4

Destructor implicitly noexcept hai, isliye agar logAppend throw kare, exception escape hoga → std::terminate. Fix: ise escape mat hone do — ise destructor ke andar hi swallow kar lo:

struct Guard {
    ~Guard() noexcept {                 // promise honestly rakho
        try { logAppend("closed"); }
        catch (...) { /* log failure ignored — cannot crash us */ }
    }
};

Yeh correct kyun hai: throw ab contained hai (andar hi caught ho gaya), isliye kuch escape nahi hota aur noexcept promise hold karta hai. Yeh canonical pattern hai: destructors aur doosre "must-not-throw" operations jo internally risky kaam karte hain unhe khud sab kuch catch karna chahiye. L3.1(ii) yaad karo: andar-caught throw kabhi contract violate nahi karta.

Recall Self-test checklist

Khud ko L1→L5 rate karo. Kya main noexcept(false) padh sakta hoon aur jaanta hoon ki iska matlab may-throw hai? ::: L1 done. Kya main noexcept(safe() + risky()) evaluate kar sakta hoon aur jaanta hoon ki operand unevaluated hai? ::: L2 done. Kya main decide kar sakta hoon ki kya ek body terminate trigger karti hai yeh poochh kar "kya yeh escape karta hai?" ::: L3 done. Kya main vector ke move-vs-copy branch ko strong guarantee ke zariye explain kar sakta hoon? ::: L4 done. Kya main explain kar sakta hoon ki noexcept function pointer plain mein convert kyun hota hai lekin vice versa nahi? ::: L5 done.