5.2.30 · D5 · HinglishC++ Programming

Question banknoexcept specifier

1,391 words6 min read↑ Read in English

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

Har item ek line hai: ek claim/question, phir :::, phir reasoning. Reasoning hi asli point hai — kabhi bhi sirf "yes/no" pe mat ruko.


True or false — justify karo

Ek noexcept function guaranteed crash nahi karegi.
False — noexcept sirf yeh promise karta hai ki koi exception escape nahi karegi; function abhi bhi segfault, deadlock, ya infinite-loop kar sakti hai. noexcept specifier dekho: yeh ek throw-promise hai, safety guarantee nahi.
noexcept akele bilkul noexcept(true) jaisa hi hai.
True — bina parentheses ke noexcept likhna noexcept(true) ka shorthand hai, yani "kabhi throw nahi karta" wala promise.
Koi bhi ordinary function jisme koi specifier nahi hai, use noexcept(true) maana jaata hai.
False — ordinary functions ke liye default noexcept(false) hota hai (may throw); sirf special members jaise destructors implicitly noexcept(true) hote hain.
Agar ek noexcept function internally throw kare lekin return se pehle use catch kar le, to contract toot jaata hai.
False — sirf woh exception jo function se escape kare, std::terminate trigger karta hai; ek try/catch jo use puri tarah swallow kar le woh bilkul legal hai.
Har function ko noexcept mark karna ek free performance win hai.
False — agar aisi function actually throw kar sakti hai, to tumne ek std::terminate ka landmine laga diya hai; ek jhootha promise ek recoverable error ko instant crash mein badal deta hai.
noexcept(expr) operator actually expr run karta hai yeh dekhne ke liye ki woh throw karta hai ya nahi.
False — expr unevaluated hota hai (sizeof ki tarah); operator declared throwing behaviour ke baare mein ek compile-time question poochtha hai, kuch execute nahi hota.
C++11 mein ek destructor jo throw kare std::terminate call karega.
True — C++11 se destructors implicitly noexcept hain, isliye ek escaping throw promise toddta hai aur terminate karta hai. Destructors dekho.
std::vector reallocation ke waqt hamesha elements ko move karta hai.
False — woh tab hi move karta hai jab element ka move constructor noexcept ho; warna Strong exception guarantee preserve karne ke liye copy karta hai.
noexcept(noexcept(x)) mein typo hai — keyword ko nest nahi kar sakte.
False — yeh intentional hai: bahar wala specifier hai, andar wala operator hai jo uske liye bool compute karta hai. Ek keyword, do roles.
Ek noexcept specifier compiler ko just-in-case exception-handling tables generate karne par majboor karta hai.
False — poora fayda iska ulta hai: compiler yahan unwinding machinery skip kar sakta hai, aur yahi wajah hai ki agar tum jhoothe nikle to woh unwind karne ki jagah terminate karta hai.

Error pakdo

void f() noexcept { throw std::runtime_error("x"); } — kya galat hai?
Exception ek noexcept function se escape karti hai, isliye std::terminate turant fire hota hai; yeh ek jhoota promise hai, compile error nahi.
std::vector<T> v; resize pe sirf isliye fast ho jaata hai kyunki T ka move constructor hai.
Move constructor ka hona kaafi nahi — woh noexcept bhi hona chahiye, warna move_if_noexcept copy karne par fall back kar jaata hai.
constexpr bool b = noexcept(risky()); jahan int risky() { throw 1; } — kya b true hai?
b false hai; risky ka koi noexcept promise nahi hai (default may-throw), isliye operator ko maan lena padta hai ki woh throw kar sakta hai. constexpr dekho.
~S() noexcept(false) { throw 1; } ek throwing destructor ko "fix" karta hai.
Yeh compile hoga aur apne aap terminate call nahi karega, lekin kisi doosri exception ki stack unwinding ke dauran destructor se throw karna abhi bhi lethal hai — asli fix hai ki throw hi mat karo.
Ek generic swap jo unconditionally noexcept(true) likha ho woh sahi hai.
Galat — agar T ka move throw kar sakta hai, to yeh jhootha promise terminate ko arm kar deta hai; tumhe conditional form chahiye noexcept(noexcept(...)).
void g() throw(); "never throws" kehne ka modern tarika hai.
throw() deprecated/removed C++98 dynamic exception specification hai; iske jagah noexcept use karo.

Why questions

Kyun ek toota hua noexcept promise sirf rethrow karne ki jagah terminate call karta hai?
Kyunki compiler ko us function ke liye unwinding tables omit karne ki permission thi; unwind karne ke liye koi information hi nahi ho sakti, isliye ruk jaana hi ek safe choice hai.
Kyun std::vector reallocation pe throw-move type ke elements move nahi, copy karta hai?
Agar move halfway throw kar de, to kuch elements naye buffer mein honge aur kuch lost — corrupt state. Copying originals intact rakhti hai agar copy throw kare, Strong exception guarantee upheld rehti hai.
Kyun noexcept operator ka argument unevaluated rehta hai?
Sawaal yeh hai ki "kya yeh throw kar sakta hai?", jo compile time par declarations se answerable hai; ise run karna purpose defeat kar deta aur side effects cause karta. Yeh exactly sizeof ki tarah kaam karta hai.
Kyun C++11 mein destructors implicitly noexcept banaye gaye?
Ek destructor ka throw karna jab stack already kisi doosri exception se unwind ho raha ho woh undefined chaos hai, isliye language by default escape forbid karti hai. Move semantics aur Destructors dekho.
Kyun ek keyword ("kya tera move noexcept hai?") kabhi kabhi vector resize speed double kar deta hai?
Yeh container ko har element copy karne se move karne par switch kar deta hai — moves existing buffers reuse karte hain unhe duplicate karne ki jagah, isliye growth O(pointers) ho jaata hai na ki O(deep copies).
Kyun compiler khud yeh figure out nahi kar sakta ki koi function throw karta hai ya nahi?
Separate compilation units aur virtual/indirect calls ke across analysis generally undecidable hai, isliye language programmer ke explicit promise par rely karti hai.

Edge cases

Kya kisi may-throw helper ko call karne wale function par noexcept(true) lagaana poori cheez safe banata hai?
Nahi — agar us helper ki exception escape kare, to phir bhi terminate hoga; specifier inner throw ko magically nahi rokta, bas saza badal deta hai.
noexcept(expr) kya hota hai jab expr aisi cheez ho jo literally compile hi nahi ho sakti (jaise undeclared)?
Woh ill-formed hai, false nahi — operator ko ek well-formed expression chahiye; sirf throwing behaviour woh evaluate karta hai, validity nahi.
Kya ek function noexcept hai agar uske andar har operation noexcept hai lekin woh mark nahi hai?
Nahi — specifier ke bina function khud noexcept(false) hai; internally throw-free hona uski declared spec auto-promote nahi karta.
noexcept(noexcept(T(std::move(a)))) ke saath kya hoga jab T ka move deleted ho?
Inner expression ill-formed ho jaata hai, isliye specifier bhi ill-formed ho jaata hai; type simply us swap ko satisfy nahi karega, quietly may-throw banne ki jagah.
Kya ek noexcept function mein throw statement ho sakta hai aur code phir bhi valid rehe?
Haan — jab tak woh exception escape se pehle catch ho jaaye; ek bare throw x; bina surrounding catch ke leak karega aur runtime par terminate karega.
Agar move noexcept nahi hai lekin type mein koi copy constructor bhi nahi hai, to vector resize par kya karta hai?
Woh majburan move karta hai (koi copy fallback nahi), isliye ek throwing move us type ke liye strong guarantee tod sakta hai — yeh ek known trade-off hai, noexcept violation nahi.

Recall One-line self-test

Woh ek sentence jo in 80% traps resolve karta hai ::: noexcept ek escape ke baare mein promise hai, terminate se enforce kiya gaya, compiler ke liye exploit kiya gaya taaki unwinding machinery drop ho sake — bas itna hi, na zyada, na kam.