Enum class - is their a more efficient way of usage? [SOLVED]


I like to use enumerations for better readability of code. But, unfortunately, if they are just defined as enum types they can not share the same phrases.
But then using them is quite costly ... Refer to example below:

enum class RadioState {Off, PlaysRadio, DoesStreaming, Broken};
enum class LightState {Off, On, Broken};

RadioState radioState;
LightState lightState;

void setup() {

  radioState = RadioState::Off;
  lightState = LightState::Broken;

void loop() {
  static int c = 0;
  while (c < 1) {
    if (radioState == RadioState::Off) {
      Serial.println("Radio is off, enjoy the silence");
    if (lightState == LightState::Broken) {
      Serial.println("Buy a new bulb");

What I mean with costly is that I need to write, RadioState::Off, and not just Off, or:

    if (radioState == Broken) {
      Serial.println("... uhh, thats a pity!")

(which can not be compiled)

I know the reason for it (using outside class) but I was wondering if somebody has a trick to avoid that long typing things.
Matter of fact, I don't understand why C++ acts like this. radioState belong to class RadioState, so the compiler knows the class. It is also known that "Off" belongs to that class, so why forcing the programmer to write what everybody knows?

Tricks and/or background info is welcome! Thanks

you defined "scoped enumerations" and as the name indicate, they are scoped... so you do need indeed the RadioState:: or LightState:: in front of the token

you can't even use two using as the compiler would not know which type you refer to...

enum class RadioState {Off, PlaysRadio, DoesStreaming, Broken};
enum class LightState {Off, On, Broken};

void aFunction() {
  using enum RadioState; // OK
  using enum LightState;  // ERROR: RadioState:: Broken and LightState::Broken conflict

enum do not support inheritance... You could have a look at extending a base enum but that's getting complicated (see here)

If that's the kind of cost you're worried about, just use an IDE with code completion. You can use VSCode with the Clangd or C/C++ extension, the Arduino IDE 2.0 (beta), and many others.

For example, if you type if (radioState == Broken in the IDE 2.0, it'll automatically suggest RadioState::Broken, you just have to press enter to accept it. (You don't even have to type Broken, just B is usually enough.)

These look more like attributes than states to me. In my opinion, you're breaking the state paradigm here. If I were polling hardware for attributes, I would assign these separately. Perhaps it is just the naming that is asymmetrical, PlayingRadio and Streaming would be a more natural description of a state. As these names stand, there is an implication of multiple possibilities... "Aarg does streaming" does not suggest that I am streaming right now, only that I am capable of it.

Ah, ok, this is getting too complicated at least for me ... nevertheless, thanks for the tip.

It was together with long lines in the code wrapping up, .... But, ok, from previous answer I get the feeling I have to live with it. I'll have a look on IDE 2.0 (beta). Thanks.

Same for "PlaysRadio", isn't it? Might be a capability two. But I think you have taken my example code to serious - it was written as educational example for using enum class (to keep it short), so I wasn't looking too close to other aspects of coding ...

Consider this thread as solved. Thanks for tipps.

I think educational examples should be taken even more seriously than production code.

Matter of fact I spend some thoughts on how to set up a proper sample code to describe what I'm interested in. And here I have taken PlaysRadio and DoesStreaming as states, not as capabilities. So why not PlaysStreaming then? Well, doesn't sound good to me, same for DoesRadio....
Example has fit into my level of C++ skills, and the intention to guide beloved audience here to the topic I'm interested.
Nevertheless, proper naming is key not to get confused, for sure!

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.