I know that if I defined an enum weekday like this:
enum weekday {
MON,
TUE,
WED,
THU,
FRI,
};
Then, MON would internally e
Just to complement on other answers, I'll give you a practical example of how using the same value for different enumerations on a given enum
is widely useful:
enum slots_t {
SLOT_FIRST = 0,
SLOT_LEFTARM = SLOT_FIRST,
SLOT_RIGHTARM = 1,
SLOT_TORSO = 2,
SLOT_LEFTLEG = 3,
SLOT_RIGHTLEG = 4,
SLOT_LAST = SLOT_RIGHTLEG
};
Then you can do in your code:
for (int i = SLOT_FIRST; i <= SLOT_LAST; ++i) { }
C enums are "really" integers -- not just because they happen to be implemented that way, but because the standard defines enum types to have integer values. So the value of today
is "really" 0. All that has happened is that you've created two different names for the value 0.
I suppose then that the answer to "is today MON or TUE" is "yes" ;-)
The language doesn't stop you because occasionally it's useful for an enum to have multiple names for the same value. For example:
enum compression_method {
COMP_NONE = 0,
COMP_LOW = 1,
COMP_HIGH = 2,
COMP_BEST = 2,
COMP_FASTEST = 0,
};
It's as philosophical (or not) as
#define ZILCH 0
#define NADA 0
There are many uses where it makes sense to have different names result in the same number.
The name of the enumeration constant is used to assign the value and not the actual value itself. If you assign the value 0 to today the output value will be 0. And yes, both MON and TUE will have the value 0 and the remaining will assigned the value as WED=1 THU=2 and so on.
Why can two different enumeration-constants have the same integer value?
Because it is explicitly allowed by the N1265 C99 standard draft at 6.7.2.2/3 "Enumeration specifiers":
The use of enumerators with
=
may produce enumeration constants with values that duplicate other values in the same enumeration.
How would a system differentiate MON and TUE internally?
I think it is impossible because they are compile time constants (6.6/6 "Constant expressions"). As a consequence they:
cannot be modified to make them differ after compilation
have no address to tell them apart: Memory location of enum value in C
Compile time constants don't need any address because addresses are useless for things which you cannot modify.
GCC simply replaces the usage of enum members with immediate values in assembly at compile time. Consider:
#include <stdio.h>
enum E {
E0 = 0x1234,
E1 = 0x1234
};
int i = 0x5678;
int main() {
printf("%d\n", E0);
printf("%d\n", E1);
printf("%d\n", i);
return 0;
}
Compile and decompile with GCC 4.8 x86_64:
gcc -c -g -O0 -std=c89 main.c
objdump -Sr main.o
The output contains:
printf("%d\n", E0);
4: be 34 12 00 00 mov $0x1234,%esi
...
printf("%d\n", E1);
18: be 34 12 00 00 mov $0x1234,%esi
...
printf("%d\n", i);
2c: 8b 05 00 00 00 00 mov 0x0(%rip),%eax # 32 <main+0x32>
2e: R_X86_64_PC32 i-0x4
32: 89 c6 mov %eax,%esi
So we see that:
$0x1234
, so it is impossible to know where they came fromi
however comes from memory 0x0(%rip)
(to be relocated), so two variables could be differentiated by address