2

I know that and standards state that if you don't specify first element's value a start value of enum will default to 0.
But e.g. in Linux kernel sources I faced strange declarations dozens of times. e.g. numa_faults_stats:

enum numa_faults_stats {
    NUMA_MEM = 0,
    NUMA_CPU,
    NUMA_MEMBUF,
    NUMA_CPUBUF
};

What is the need for explicitly set first element of this enum to 0?

Related post.

budoattack
  • 379
  • 3
  • 11
  • 6
    Some programmers like to be explicit. There's no other reason. – Barmar Aug 10 '20 at 16:53
  • 2
    Zero is the default value in both C and C++, so it makes no difference. I guess some folks just like to be more explicit. – Fred Larson Aug 10 '20 at 16:53
  • 1
    This is a typical case on something I'd remark on during code review. "Why did you write 0 here? If you can give a sensible rationale, you may keep the code as it is." They can't. Same category as similar dumb stuff like `return (0);` or `int x = {0};`. Writing superfluous stuff like that is almost always an indication of an insecure programmer who aren't quite certain how the language works. – Lundin Aug 11 '20 at 11:38

2 Answers2

3

There are very many rules for various things in C and C++: this being one of them. Sometimes it's nice to be explicit, for clarity.

Another common one is to use variable names in function prototypes (only the types are needed). Yet another is a return 0; in main in either language. The explicit use of public and private in a C++ class or struct is another.

Bathsheba
  • 231,907
  • 34
  • 361
  • 483
  • I would also add it can remove cognitive dissonance here too. Seeing which one is explicitly the 0 value can be useful when someone is refactoring to get rid of magic numbers or just needs to know the default. – Mgetz Aug 10 '20 at 16:57
  • @Bathsheba, I respectfully disagree. Using variable names in function prototypes is good for documentation and those name can not be guessed (so as their possible usage). But Zero is an easy number to remember and having the zero for the first member of an enum is a rule that every decent c/c++ programmer should know. I do not think those two are comparable. As for the case of explicit use of public/private, I some what agree with you. But again I don't think it is comparable. But thank you for the answer any way. I was really beginning to think that there is a real logical reason behind it. – AKL Aug 15 '22 at 16:12
3

You can use enums without care its value like only using it comprasions with each other. But sometimes its value is important. You may use is as an index of an array. eg.

 struct NUMA Numa[N];
 Numa[NUMA_MEM];
 Numa[NUMA_CPU];

In this case it is definitly good idea explicitly assing value even it is default equal. You emphasize that its value has usage in code.

I S
  • 436
  • 3
  • 7
  • Indeed; this is a sort of convention I have too (e.g. C++03 metaprogramming techniques). And such code always needs a comment. – Bathsheba Aug 10 '20 at 17:25
  • Yes, this is the right answer: use initializers when they matter. If you don't care what the particular values are, just that they are different, there's no need to explicitly state what the values are. +1. – Pete Becker Aug 10 '20 at 17:50
  • 1
    Such code should rather have been written as `enum { NUMA_MEM, ... NUMA_N };` then `struct NUMA Numa[NUMA_N];`. Optionally with a `static_assert(sizeof Numa/*sizeof Numa == NUMA_N, "The enum is crap.");` – Lundin Aug 11 '20 at 11:40
  • @I S. I respectfully disagree. Even if a value of a enum is important, a quick look at the enum definition is enough to see that is the first member, therefore it is zero. IMO, it become confusing when I see zeros in front of the first enum members! – AKL Aug 15 '22 at 16:23