In Java, enum values behave like objects (since they are basically syntactic sugar for objects) and they can have their own class methods. In C++, however, enums are essentially an alias for an integer constant.
What are some possible situations where a Java type enum would be better/make more sense to be used and when would a C++ enum make more sense in a language?
For a complete comparison, we should add a 3rd (and 4th?) type of enum: Sum Types, as in Haskell or Rust.
C and C++ plain enum are unscoped. That is, their enumerators are part of the enclosing scope of the declaration1. This is largely seen as undesirable.
A contrario, Java, Haskell, and Rust's "enumerators" are scoped.
1 In the early days of C, struct data members were also unscoped. This is why struct tm data members are all prefixed with tm_. struct data members were changed to be scoped, but enums were not.
C and C++ enum (plain or class) are partial, they are not guaranteed to hold a value matching an enumerator, and may instead hold any value achievable by bitwise ORing enumerators or, in the case of C++, any value which may fit in the specified underlying type, if any.
Java, Haskell, and Rust fully define the valid enumerators, and no other value is supported.
Advantage C/C++
enum can be used as a set of flags.Advantage Java/Haskell/Rust
enum are not meant to be used as set of flags, so not having to worry about an exotic unnamed state is generally beneficial.Advantage Rust
Option<E> where E is an enum, has the same size as E.C and C++ enum may have multiple "equal" enumerators, that are indistinguishable from one another.
Java, Haskell, and Rust cannot have indistinguishable enumerators.
C and C++ enum are integers in disguise, their integer value can be specified and they can always be converted down to their integer representation. Similarly, in-range integers can be converted to enum.
Rust enum with no payloads can have a specified underlying integer representation (#[repr(u8)] is common) and specified integer values, in which case they can be converted to this representation (e as u8). There is no automatic conversion back from integer, as not all values may be valid enum values, but a user-written conversion function can be optimized down to the equivalent cast.
Java enum can be converted to an int using the ordinal method, the integer value is the index of the enumerator in the declaration.
Advantage C/C++/Rust
enum can be used to enumerate a fixed set of related integral constants, at no run-time cost.Java enum can have a state, though all enumerators must have the same set of fields.
Haskell and Rust enums are full sum types which can have a different set of fields per enumerator.
Advantage Java
Advantage Haskell/Rust
Maybe (Haskell) and Option (Rust) types completely eliminate the Billion Dollars mistake that is null, for example.C and C++ enum do not support methods.
Java, Haskell, and Rust enums are first-class user-defined types of the language, and support everything user-defined types do: associated constants, inherent methods, inheritance (Java) or typeclass/trait (Haskell/Rust) implementations, etc...
First, a classification by versatility:
Getting down to the details, the one task that C and C++ enums can fulfill better than others is the role of set of flags if the enumerators are carefully defined. Java, Haskell, and Rust require user-written code to efficiently encode enum sets of integers, with Rust (at least) being able to optimize that code down to same assembly as C or C++.
Otherwise, first-class citizens enum are always preferable, and sum-types even more preferable.
OptionSet: langdev.stackexchange.com/a/1671/15 So that missing functionality of an enum isn't really felt.
$\endgroup$
E by itself, when needed, and have my EnumSet<E> and EnumMap<E, V>.
$\endgroup$
Commented
Jul 27, 2023 at 14:34
edges(EDGE_LEFT | EDGE_TOP) or edges(edge::left | edge::top) as in C++, Swift allows you to say edges([.left, .top]). There's no namespace pollution nor loss of type safety, yet it's briefer. Plus, you don't have to worry about whether it takes a Set<Edge> or an OptionSet type: the API is the same.
$\endgroup$
std::variant in C++ is an interesting "enum". I sometimes do std::variant<std::integral_constant<...>...> even.
$\endgroup$
Commented
Jul 28, 2023 at 3:52
std::visit and match (Rust) is just night and day :(
$\endgroup$
Commented
Jul 28, 2023 at 6:49
In C++ you can have a plain enum or an enum class, and the enum class is similar in some way to Java enums. So plain enum are more likely the one you are describing here when you say C++ enum.
In that case, enums are indeed aliases for integer constants: they convert automatically to the underlying type, even you don't want to, from a static typing point of view there is little difference. There can be values that belong the an enum type even if there is no enum with that value: if you define three values A, B and C (resp. bound to 0, 1 and 2), then A|B|C is a bitwise-or value equal to 3, which takes 2 bits and fits the underlying type of the enum, however this is not a proper enum value by itself.
A Java-type enum object can list all its values at runtime. The set of values is restricted to only the values that are defined by the enum, you cannot use an enum and an int interchangeably, you have to call the associated methods to convert from and to integers, from and to strings, etc.
I think there is little added-value for plain enums compared to, e.g. constants (or even preprocessor variables). A group of constants declarations is almost equivalent: the notation is shorter with plain enums, and there is an additional relationship between constants that is expressed by the construct. Only enum classes introduce a scope, for example (nb. compared to Java enums, enum classes in C++ don't have reflection).
Java-style enums are the standard now I think for any high-level language, when it is acceptable to have a little bit of runtime features that help the programmer. Writing low-level, resource contrained code is maybe the only case where I see a benefit in using plain enums.
struct, though at that point you're essentially just reinventing Java-style enums. (That said, it's also worth pointing out that as truly constant values, enum-in-struct was often used to provide constexpr-like functionality before C++11, for things like std::string::npos or template metaprogramming.)
$\endgroup$
Commented
Jul 27, 2023 at 6:13
enum for a group of constants => lints. C and C++ compilers have warning if you forget to handle an enumerator in a switch, and no equivalent for constants. There are also hacks to enumerate the enumerators of an enum in C++ (magic meta-template wizardry), for pseudo-reflection.
$\endgroup$
Commented
Jul 27, 2023 at 12:44
C++ enums are essentially just int constants. This makes them efficient to implement, and usable for low-level or performance-critical programs.
OTOH, Java-style enums have full class functionality. They provides better type safety (since you can't just implicitly convert them to/from int). It also lets you define fields and methods for additional functionality (e.g., custom string formatting and parsing).
Of course, you're not constrained to what's provided by your language's enum keyword. It's possible to implement a C++ class that behaves like a Java enum, or a Java class that just defines a bunch of public static final int constants like a C(++) enum.
To recap,
int" doesn't really depend on whether the enums are classes or just ints under the hood. The compiler can still refuse to let you cast implicitly, or even do the reverse and allow implicitly casting an int to an enum class
$\endgroup$
When programming in C++ I sometimes miss the additional methods that come automatically with Java enums, especially an easy way to converted into string representation when logging, but also for parsing, obtaining next or previous value in the order and the like. In C++, you need to write your own free-standing functions to replace them. Free-standing functions are then quite difficult to find by another programmer who is not aware of them.
