Is there any reason to use an enumeration to define a single constant in C ++ code?

A typical way to define an integer constant to use inside a function is:

const int NumbeOfElements = 10; 

same for use inside class:

 class Class { ... static const int NumberOfElements = 10; }; 

It can then be used as a fixed-size array binding, which means it is known at compile time.

For a long time, compilers did not support the latter syntax and therefore used enumerations:

 enum NumberOfElementsEnum { NumberOfElements = 10; } 

Now almost every widely used compiler that supports the syntax in-function const int and in-class static const int , is there any reason to use an enumeration for this purpose?

+11
c ++ enums constants
Sep 04 '09 at 7:26
source share
9 answers

The reason is mostly brevity. First of all, enum can be anonymous:

  class foo { enum { bar = 1 }; }; 

This effectively introduces bar as an integral constant. Note that the above is shorter than static const int .

Also, no one could write &bar if he is a member of enum . If you do this:

  class foo { static const int bar = 1; } 

and then your class client does this:

  printf("%p", &foo::bar); 

then it will get the linker-time-linker error that foo::bar is undefined (because, well, like lvalue, it’s not). In practice, with the standard that currently stands, somewhere bar used where an integral constant expression is not required (i.e. where it is just allowed), it requires a definition outside the class foo::bar. such an expression is necessary: enum initializers, case labels, the size of the array in types (except for new[] ), and template arguments for integral types. Thus, the use of bar elsewhere technically requires determination. See C ++ Core Language Active Issue 712 for more details - no offers yet.

In practice, most compilers these days are more lenient to this and will allow you to avoid most of the "sound reasoning" of using static const int variables without requiring a definition. Nevertheless, angular cases may vary, but many believe that it is better to use an anonymous enum , for which everything is extremely clear, and there is no ambiguity at all.

+23
Sep 04 '09 at 8:09
source share

The definition of static constants directly in the class definition is a later addition to C ++, and many of them still follow the older workaround for using enum to do this. There may even be several older compilers that are still in use that do not support static constants directly defined in class definitions.

+9
Sep 04 '09 at 7:35
source share

In your case, I would use a constant. However, there are other cases where I can add other related constants. Like this:

 const int TextFile = 1; // XXX Maybe add other constants for binary files etc.? 

In such cases, I use an enumeration immediately with a single value, for example:

 enum FileType { TextFile = 1 // XXX Maybe add other values for binary files etc.? } 

The reason is because the compiler can give warnings when I use a constant value in switch expressions, for example:

 FileType type; // ... switch ( type ) { case TextFile: // ... } 

If I decided to add another constant value that is associated with an existing value (in this example, a different file type), almost all compilers will give a warning, because the new value is not processed in the switch statement.

If I used 'int' and constants instead, the compiler would not be able to issue warnings.

+5
Sep 04 '09 at 7:36
source share

The only reason to use "enum hack" is because older compilers do not support const class definitions, as you say in your question. So, if you do not suspect that your code will be ported to the old compiler, you should use const, where const. It must be.

+5
Sep 04 '09 at 7:38
source share

Using an enumeration has one advantage. An enum type is a type, so if you define, for example:

 enum EnumType { EnumValue1 = 10, EnumValue2 = 20 ... }; 

and you have a function like:

 void Function1(EnumType Value) 

the compiler checks that you pass the enum element EnumType to the function, so only valid values ​​for the Value parameter will be EnumValue1 and EnumValue2. If you use constants and change the function to

 void Function1(int Value) 

the compiler checks that you pass int (any int, constant, variable or literal) to the function.

Enum types are good for grouping related const values. For just one const value, I see no benefits.

+5
Sep 04 '09 at 7:56
source share

I think that there is no reason to use an enumeration and that it is better to use static const int for this purpose, since the enumeration has its own type (even if it is implicitly converted to an integer).

+3
Sep 04 '09 at 7:35
source share

There is a difference between the two. As far as I know, listings do not have an address. static const ints. Therefore, if someone takes the address of static static int, discards the const, he can change the value (although the compiler can ignore the change because he thinks he is const). This, of course, is pure evil, and you should not do this, but the compiler cannot prevent this. This cannot happen with transfers.

And, of course, if you (for some reason) need the address of this const, you will need a static const int.

In short - enum is an rvalue, and const static int is the value of l. See http://www.embedded.com/story/OEG20011129S0065 for more details.

+2
Sep 04 '09 at 8:05
source share

Well, portability is a good reason to use enumeration. This is great because you don't have to worry if your compiler supports "static const int S = 10" or not ...

In addition, as far as I remember, a static variable should be defined somewhere, and also declared, and the enumeration value should be declared only.

+1
Sep 04 '09 at 7:38
source share

bottom line - use a constant.

more details:

I'm not an expert in C ++, but this seems like a more general design issue.

If this is not necessary, and you consider that there is a very low / nonexistent probability that the enumeration will have more than one value, then use regular const. even if you are mistaken, and at some point in the future there will be more values, which makes enumeration the right choice - simple refactoring, and you change const to enumeration.

-2
Sep 04 '09 at 7:30
source share



All Articles