Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. Use #define or enum in switch() case(s) ?

Use #define or enum in switch() case(s) ?

Scheduled Pinned Locked Moved C / C++ / MFC
questiontutorial
10 Posts 5 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • V Offline
    V Offline
    Vaclav_
    wrote on last edited by
    #1

    Academic question. Which do you prefer - using preprocessor directive #define to replace case state - example "case 0:" with #define NORTH 0 and code "case NORTH:" or use enum? Here is a sample code using enum: Enumerated variables have a natural partner in the switch statement, as in the following code example. #include enum compass_direction { north, east, south, west }; enum compass_direction get_direction() { return south; } /* To shorten example, not using argp */ int main () { enum compass_direction my_direction; puts ("Which way are you going?"); my_direction = get_direction(); switch (my_direction) { case north: puts("North? Say hello to the polar bears!"); break; case south: puts("South? Say hello to Tux the penguin!"); break; case east: puts("If you go far enough east, you'll be west!"); break; case west: puts("If you go far enough west, you'll be east!"); break; } return 0; }

    P J A V 4 Replies Last reply
    0
    • V Vaclav_

      Academic question. Which do you prefer - using preprocessor directive #define to replace case state - example "case 0:" with #define NORTH 0 and code "case NORTH:" or use enum? Here is a sample code using enum: Enumerated variables have a natural partner in the switch statement, as in the following code example. #include enum compass_direction { north, east, south, west }; enum compass_direction get_direction() { return south; } /* To shorten example, not using argp */ int main () { enum compass_direction my_direction; puts ("Which way are you going?"); my_direction = get_direction(); switch (my_direction) { case north: puts("North? Say hello to the polar bears!"); break; case south: puts("South? Say hello to Tux the penguin!"); break; case east: puts("If you go far enough east, you'll be west!"); break; case west: puts("If you go far enough west, you'll be east!"); break; } return 0; }

      P Offline
      P Offline
      PIEBALDconsult
      wrote on last edited by
      #2

      enum.

      1 Reply Last reply
      0
      • V Vaclav_

        Academic question. Which do you prefer - using preprocessor directive #define to replace case state - example "case 0:" with #define NORTH 0 and code "case NORTH:" or use enum? Here is a sample code using enum: Enumerated variables have a natural partner in the switch statement, as in the following code example. #include enum compass_direction { north, east, south, west }; enum compass_direction get_direction() { return south; } /* To shorten example, not using argp */ int main () { enum compass_direction my_direction; puts ("Which way are you going?"); my_direction = get_direction(); switch (my_direction) { case north: puts("North? Say hello to the polar bears!"); break; case south: puts("South? Say hello to Tux the penguin!"); break; case east: puts("If you go far enough east, you'll be west!"); break; case west: puts("If you go far enough west, you'll be east!"); break; } return 0; }

        J Offline
        J Offline
        Jochen Arndt
        wrote on last edited by
        #3

        As already answered, enum is better. One advantage is that modern compilers can throw a warning when not all enums are handled by the switch statement. So you will be noticed when you forgot to handle a newly added definition.

        1 Reply Last reply
        0
        • V Vaclav_

          Academic question. Which do you prefer - using preprocessor directive #define to replace case state - example "case 0:" with #define NORTH 0 and code "case NORTH:" or use enum? Here is a sample code using enum: Enumerated variables have a natural partner in the switch statement, as in the following code example. #include enum compass_direction { north, east, south, west }; enum compass_direction get_direction() { return south; } /* To shorten example, not using argp */ int main () { enum compass_direction my_direction; puts ("Which way are you going?"); my_direction = get_direction(); switch (my_direction) { case north: puts("North? Say hello to the polar bears!"); break; case south: puts("South? Say hello to Tux the penguin!"); break; case east: puts("If you go far enough east, you'll be west!"); break; case west: puts("If you go far enough west, you'll be east!"); break; } return 0; }

          A Offline
          A Offline
          Albert Holguin
          wrote on last edited by
          #4

          enum...... Preprocessor directives can make troubleshooting and reading your code tricky, not worth going down that route unless you don't have alternatives, in this case, you have a perfectly viable solution with an enum.

          1 Reply Last reply
          0
          • V Vaclav_

            Academic question. Which do you prefer - using preprocessor directive #define to replace case state - example "case 0:" with #define NORTH 0 and code "case NORTH:" or use enum? Here is a sample code using enum: Enumerated variables have a natural partner in the switch statement, as in the following code example. #include enum compass_direction { north, east, south, west }; enum compass_direction get_direction() { return south; } /* To shorten example, not using argp */ int main () { enum compass_direction my_direction; puts ("Which way are you going?"); my_direction = get_direction(); switch (my_direction) { case north: puts("North? Say hello to the polar bears!"); break; case south: puts("South? Say hello to Tux the penguin!"); break; case east: puts("If you go far enough east, you'll be west!"); break; case west: puts("If you go far enough west, you'll be east!"); break; } return 0; }

            V Offline
            V Offline
            Vaclav_
            wrote on last edited by
            #5

            One more question - since the state is changed using interrupt it needs to be declared as volatile.It compiles with "volatile enum..." so it should be correct syntax, but I cannot test it as yet - the hardware is not ready, but I will try to emulate the interrupt. AM I on the right track?

            F A 2 Replies Last reply
            0
            • V Vaclav_

              One more question - since the state is changed using interrupt it needs to be declared as volatile.It compiles with "volatile enum..." so it should be correct syntax, but I cannot test it as yet - the hardware is not ready, but I will try to emulate the interrupt. AM I on the right track?

              F Offline
              F Offline
              Frankie C
              wrote on last edited by
              #6

              No you don't have to declare enum volatile, and the compiler should give you error. This because you are creating an enumerated series of constants and they can't change. You must declare volatile your input variable, because this is the one that changes under interrupt. You must do this to advice the compiler to take care when optimizing code to make no assumptions on its value. If you don't there will be cases in which the compiler will assume that the variable is in a specific condition and will omit some code or use an old value.

              V 1 Reply Last reply
              0
              • F Frankie C

                No you don't have to declare enum volatile, and the compiler should give you error. This because you are creating an enumerated series of constants and they can't change. You must declare volatile your input variable, because this is the one that changes under interrupt. You must do this to advice the compiler to take care when optimizing code to make no assumptions on its value. If you don't there will be cases in which the compiler will assume that the variable is in a specific condition and will omit some code or use an old value.

                V Offline
                V Offline
                Vaclav_
                wrote on last edited by
                #7

                Thanks, the "problem" is that Arduino IDE "compiler" is so "automated" AKA stuff is hidden from user. It did not complain when I tested this base code. At present the input "pins" array is not volatile and I'll change that. I have a small additional challenge implementing the ISR ( interrupt service routine). The interrupt code involves callback and is defined as Arduino API. The ISR does not accept any parameters , consequently each interrupt process implementation has to have its own ISR. So in theory the input ( variable ) is processed only in one place. It is convoluted mess and I am working on it. But I needed the basic state machine to work first. SO far so good.

                1 Reply Last reply
                0
                • V Vaclav_

                  One more question - since the state is changed using interrupt it needs to be declared as volatile.It compiles with "volatile enum..." so it should be correct syntax, but I cannot test it as yet - the hardware is not ready, but I will try to emulate the interrupt. AM I on the right track?

                  A Offline
                  A Offline
                  Albert Holguin
                  wrote on last edited by
                  #8

                  Somewhat unrelated to your original question but........ REMOVE ALL THOSE #defines! That is some ugly code! If you need a #define on a print function, do it once with a macro and not every single place you want to use that function.

                  //pseudo-code
                  #ifdef DEBUG
                  #define UTIL_PROC(X) Utility_LCD_Process((X));
                  #else
                  #define UTIL_PROC(X)
                  #endif

                  //When using it, you just call the macro
                  case LED_on:
                  {
                  UTIL_PROC("case LED_on")
                  State_Array[iInputPin] = LED_off;
                  break;
                  }

                  V 1 Reply Last reply
                  0
                  • A Albert Holguin

                    Somewhat unrelated to your original question but........ REMOVE ALL THOSE #defines! That is some ugly code! If you need a #define on a print function, do it once with a macro and not every single place you want to use that function.

                    //pseudo-code
                    #ifdef DEBUG
                    #define UTIL_PROC(X) Utility_LCD_Process((X));
                    #else
                    #define UTIL_PROC(X)
                    #endif

                    //When using it, you just call the macro
                    case LED_on:
                    {
                    UTIL_PROC("case LED_on")
                    State_Array[iInputPin] = LED_off;
                    break;
                    }

                    V Offline
                    V Offline
                    Vaclav_
                    wrote on last edited by
                    #9

                    Good suggestion, however I did moved the #ifdef / #endif to the function itself so it does look cleaner. Actually - is the #else necessary?

                    A 1 Reply Last reply
                    0
                    • V Vaclav_

                      Good suggestion, however I did moved the #ifdef / #endif to the function itself so it does look cleaner. Actually - is the #else necessary?

                      A Offline
                      A Offline
                      Albert Holguin
                      wrote on last edited by
                      #10

                      If you're using my method, yes... otherwise the compiler will tell you that function is undefined.

                      1 Reply Last reply
                      0
                      Reply
                      • Reply as topic
                      Log in to reply
                      • Oldest to Newest
                      • Newest to Oldest
                      • Most Votes


                      • Login

                      • Don't have an account? Register

                      • Login or register to search.
                      • First post
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • World
                      • Users
                      • Groups