Enumerations: Question bank — Hinglish deep dive

5.1.25 · D5 · Coding › C Programming › Enumerations

Shuru karne se pehle, wo anchor fact yaad karo jo aadhe traps dissolve kar deta hai: ek enum ki values kisi implementation-chosen integer type mein store hoti hain — woh compiler khud choose karta hai jo har enumerator ki value hold kar sake (yeh int ho sakta hai, ya wider/narrower signed ya unsigned integer type; standard int ki guarantee nahi deta). Enumerators khud, though, expressions mein use hone par int type ke hote hain. Dono cases mein, runtime par sirf ek integer hota hai; names compile-time labels hain jo compilation ke baad gayab ho jaate hain. Integer Types in C dekho "an integer type" ka matlab samajhne ke liye — iska signedness aur size platform-dependent hai, jo portability ke liye matter karta hai.

Neeche ka number line mental model hai: names sirf integer positions par sticky-notes hain, aur counting rule daayein taraf ek-ek karke chalta hai.

True ya false — justify karo

printf("%d", RED) for enum { RED, GREEN } prints the word "RED".

False. C sirf integer store karta hai, toh yeh 0 print karega. Python ke repr jaisa koi name-lookup table nahi hai; names print karne ke liye tum khud const char* names[] banate ho.

Ek enum ek bilkul naya type introduce karta hai jise compiler plain int ke saath mix karne se mana karta hai.

False. C mein ek enum value freely int se convert hoti hai aur int mein bhi, toh enum Color c = 99; bina kisi error ke compile hota hai. "Type" documentation hai, enforcement nahi — woh safety C++ mein hai, C mein nahi.

Same enum mein do enumerators ko same integer value hold karne ki permission hai.

True. Sirf names scope mein unique hone chahiye; enum { WARN = 5, FATAL = 5 } bilkul legal hai kyunki do sticky-notes ek hi locker ko label kar sakte hain.

Ek enumerator tak pahunchne ke liye Color.RED likhna zaroori hai, jaise ek struct field.

False. Enumerators surrounding scope mein plain identifiers hain, toh sirf RED likhte hain. Yahi wajah hai ki ek scope mein do enums ek naam reuse nahi kar sakte — unlike struct in C jiske members s.field ke roop mein reach kiye jaate hain aur struct ke andar scoped hote hain.

Ek baar explicit value assign karne ke baad, baad ke saare enumerators ko bhi explicit hona chahiye.

False. "+1 over previous" rule kabhi rukta nahi; A = 5 ke baad ek unassigned B becomes 6. Explicit values sirf count ko restart karti hain, disable nahi karti.

Ek enum constant ko ek switch statement mein case label ke roop mein use kiya ja sakta hai.

True. Kyunki enumerators compile-time integer constants hain, yeh switch ki requirement poori karte hain ki har case ek constant expression ho — yahi wajah hai ki enums aur switch itne naturally pair karte hain.

Enum values strings ke roop mein store hoti hain isliye yeh ints se zyada memory lete hain.

False. Yeh ek implementation-chosen integer type mein store hote hain, kabhi strings mein nahi. Names ka runtime par koi cost nahi hoti — yeh compilation ke baad gayab ho jaate hain.

enum Weekday { MON, TUE }; same memory use karta hai chahe tum MON likhho ya 0.

True. MON compilation ke baad 0 hi hai; yeh runtime par byte-for-byte identical hain. Naam sirf badalta hai jo ek insaan source padhte waqt dekhta hai.

struct S { int x; } mein field aur enum { RED } mein RED ek hi tarah ke scope mein rehte hain.

False. Struct ka x ek member hai, sirf s.x se reach hota hai; enum ka RED ek top-level identifier hai jo bare reach ho sakta hai. Yahi farq hai ki do enums ek naam share nahi kar sakte lekin do structs mein dono ka member x ho sakta hai.

Error dhundho

enum Color { RED, GREEN, BLUE } phir if (c == "RED") — kya galat hai?

c ek integer hai aur "RED" ek string literal (char* address) hai, toh tum ek int ko pointer se compare kar rahe ho — meaningless, aur modern compilers warn karte hain ("comparison between pointer and integer"), jo -Werror ke under hard error ban jaata hai. Tumhara matlab tha if (c == RED), int ko 0 se compare karna.

enum A { X }; enum B { X }; same file mein — yeh kyon fail hota hai?

Dono surrounding scope mein X naam ka ek identifier declare karte hain, aur ek scope mein do cheezein same naam ki nahi ho sakti. Enumerators apne enum se namespaced nahi hote, toh doosra X collide karta hai.

switch(c) { case RED: puts("stop"); case GREEN: puts("go"); } — bug?

case RED ke baad missing break fall-through ka cause banta hai: RED match hone par dono "stop" aur "go" print hote hain. switch mein har intentional case ko normally apna break chahiye.

enum E { A = 1, B, A = 4 }; — legal?

Illegal — value 4 ki wajah se nahi, balki isliye ki naam A do baar declare hua hai. Duplicate values theek hain; duplicate names actual violation hai.

typedef enum { RED, GREEN } Color; enum Color c; — kya galat hai?

Enum ka koi tag nahi hai (enum ke baad kuch nahi), toh enum Color kisi type ka naam nahi hai — yeh sirf redundant nahi, yeh ek hard compile error hai. Typedef ne pehle hi Color ko type name bana diya, toh enum keyword ke bina Color c; likhna hoga.

const char* name = RED; jahan RED ek enumerator hai — kya toot jaata hai?

RED integer 0 hai, toh yeh name ko null pointer assign karta hai (integer 0 pointer mein convert hota hai). Tumhe chahiye tha names[RED] lookup array, RED khud nahi.

Why questions

Pehla un-initialized enumerator 0 kyun pata hai aur 1 nahi?

Kyunki C standard bina initializer wale pehle enumerator ko 0 fix karta hai, C ki zero-based habit se match karta hua (jaise array indices). Baaki sab ek hi recurrence "previous + 1" se follow hota hai.

Duplicate enum values allowed kyun hain lekin duplicate names forbidden kyun hain?

Ek value sirf ek number hai jo machine store karta hai, aur kuch nahi toot ta agar do labels same number point karein. Ek naam ek identifier hai jise compiler ek cheez mein resolve karna chahiye, toh do identical names ambiguous honge.

Related constants ke set ke liye #define ke bajaye enum prefer kyun karein?

Enums ek logical type ke roop mein grouped hain, scope follow karte hain, aur debugger aur switch warnings mein dikhte hain; #define raw text substitution hai bina us structure ke. Enum document karta hai "yeh sab ek saath belong karte hain."

Trailing-COUNT trick automatically items ki count kyun equals hoti hai?

Kyunki counting 0 se shuru hoti hai, position n par ek item ki value n hoti hai, toh last real item ke baad placed enumerator exactly count par land karta hai. Pehle ek aur item add karo aur recurrence COUNT ko automatically bump kar deta hai — Arrays in C size karne ke liye useful.

C kyun nahi bata sakta agar tumne enum Color mein 99 jaisi nonsense value assign ki?

Kyunki C enum ko ordinary integer treat karta hai, aur 99 valid integer hai. C yahan deliberately type-safety ko simplicity aur speed ke liye trade karta hai — "kya yeh real color hai?" ka burden tumhara hai.

printf("%d", GREEN) kaam karta hai agar enums "ek type" hain?

Kyunki expressions mein ek enumerator ka type int hota hai, aur %d exactly int expect karta hai — match trivial aur lossless hai. Agar enums sach mein strict types hote, toh iske liye cast chahiye hota; C mein nahi hota.

Edge cases

enum { A = -3, B, C }; — B aur C kya hain?

B = -2 aur C = -1. Negative explicit values legal hain, aur "+1 over previous" rule phir bhi apply hota hai, -3 se upward chalta hua.

enum { A = 5, B = 5, C }; — C kya hai?

C = 6. C B ki value 5 se previous+1 hai, aur yeh fact ki A aur B 5 par collide karte hain, counting ke liye irrelevant hai.

enum Empty { }; — bina enumerators wala enum allowed hai?

Yeh valid C nahi hai — ek enum mein kam se kam ek enumerator zaroor ho, kyunki otherwise naam karne ya count karne ke liye kuch nahi hai. (Kuch compilers ise extension ke roop mein permit karte hain; iss par rely mat karo.)

enum { A = 2147483647, B }; jahan chosen type 32-bit signed hai — problem?

B hoga A + 1, jo ek signed 32-bit integer ko overflow karta hai, aur C mein signed integer overflow strictly undefined behavior hai (sirf implementation-defined nahi). Recurrence limits se blind hai, toh tum values ko type ki range mein rakhna — Integer Types in C dekho.

enum Color c; declare hua lekin kabhi assign nahi hua — iska kya value hoga?

Agar yeh local variable hai, toh yeh exactly kisi bhi uninitialized integer variable ki tarah garbage hai; yeh automatically RED nahi hota. Enums ko unke storage duration ke normal rules se aage koi special zero-init nahi milti.

Kya ek enumerator ki explicit value doosra enumerator ho sakta hai, jaise { A = 1, B = A }?

Haan — enumerators constant expressions hain, toh B = A sets B to 1, aur baad mein unassigned C becomes 2. Tum pehle wale se values build kar sakte ho jab tak yeh compile-time constants rahein.

Recall Lock karne ke liye ek-line summary

Enums self-documenting integer labels hain: names unique hone chahiye, values nahi; enumerators int-typed constants hain jo implementation-chosen integer type mein store hote hain; aur C almost koi type safety enforce nahi karta — upar ke har trap ko in facts ka consequence samjho. Trap-killer sentence ::: "Yeh ek integer constant hai ek acha naam ke saath, 0 se +1 se count hota hua, restartable, aur type-checked nahi."