Can anyone tell what is specialty of Switch case statement in c language ?

I can replace switch case a statement with multiple if statement as shown in second program. I do not think that switch case statement should be needed because I can make it with multiple if statement. But this is not a true, it is used at many places. What I am missing about Switch case statement ?

This is example of switch case statement

#include<stdio.h>

int main ()
{
    int N;
    printf("input : ");
    scanf("%d", &N);
    switch (N)
    {
      case 1:
          printf("First \n");
          break;
      case 2:
          printf("Second \n");
          break;         
      case 3:
          printf("Third \n");
          break;
      default:
          printf("None \n");
          break;
    }               
    return 0;
}

This example show the behavior of switch case

#include<stdio.h>

int main ()
{
    int N;
    printf("input : ");
    scanf("%d", &N);
    
    if(N==1)
        printf("First \n");
    if(N==2)
        printf("Second \n");
    if(N==3)
        printf("Third \n");
    else
        printf("None \n");
              
    return 0;
}

 

Can anyone tell what is specialty of Switch case statement in c language ?

There's a pretty good summary here. Also, Googling on the phrase "switch case vs if statements" brings up lots of other good stuff.

 

Yes, you can rewrite any program that uses a switch() statement to use only if()...else statements. In fact, you can write any program that uses if()...else statements to use only if() statements. You can also pick one of the looping structures ( for(), while(), do...while() ) and use it to eliminate the use of the other two. If you really want to get primitive, you can write your entire program using nothing but if() and goto statements for flow control.

You also don't need abbreviated assignment statements or increment/decrement operators. For instance,

x = x + 1;
x += 1;
++x;
x++;

all do the same thing.

You also don't need square brackets to access array elements as a[i] is the same as *(a+i).

So why do we have any of these available? Because they add to the expressiveness of the language, which facilitates better and quicker code creation and makes the resulting code more readable and maintainable.

There are also performance considerations -- the compiler has additional knowledge because of the constraints imposed by some of these constructs, and so it can generate better performing code in some cases, although modern compilers are getting pretty good at doing so even without those hints.

There are also a few issues when working with values that could change under other than program control and also a few security implications, but those are well beyond the scope of this discussion.

 

I would say that many language features are there because they enhance readability. Looking at a case statement provides a much better overview of what is going on than nested if-else especially if the original writer was sloppy in his use of indentation and consistent placement of curly braces. If you are ever responsible for a piece of code you did not write you may come to appreciate my point of view. Rock on Wayne!

 

My experience is that compilers for PIC processors will replace the case-switch construction with a series of tests that are the same as if you used if-else statements. The alternative would be a jump table, but that's awkward if the tests don't involve a set of consecutive numbers. And then there's the issue of crossing boundaries in the hex file where the low-order address wraps from 0xFF to 00--it's easier just to use the sequence of tests.

 

My experience is that compilers for PIC processors will replace the case-switch construction with a series of tests that are the same as if you used if-else statements. The alternative would be a jump table, but that's awkward if the tests don't involve a set of consecutive numbers. And then there's the issue of crossing boundaries in the hex file where the low-order address wraps from 0xFF to 00--it's easier just to use the sequence of tests.

Or not.

 

Yes, you can rewrite any program that uses a switch() statement to use only if()...else statements. In fact, you can write any program that uses if()...else statements to use only if() statements. You can also pick one of the looping structures ( for(), while(), do...while() ) and use it to eliminate the use of the other two. If you really want to get primitive, you can write your entire program using nothing but if() and goto statements for flow control.

we can do anything But what we are doing is we really need
another example

#include<stdio.h>
int main (){
    enum Nummbers {N1, N2, N3, N4}N;
    printf("N1 %d \n", N1);
    printf("N2 %d \n", N2);
    printf("N3 %d \n", N3);
    printf("N4 %d \n", N4);         
    return 0;
}

I can achieve behavior of enumeration with define keywords

#include<stdio.h>

#define N1   0
#define N2   1
#define N3   2
#define N4   3

int main (){
    printf("N1 %d \n", N1);
    printf("N2 %d \n", N2);
    printf("N3 %d \n", N3);
    printf("N4 %d \n", N4);
         
    return 0;
}

My question was that define and enum are two different keywords. And both of have their own importance and specialty and I am missing the special purpose. When and where, which keywords should I really need to use

 

we can do anything But what we are doing is we really need
another example

#include<stdio.h>
int main (){
    enum Nummbers {N1, N2, N3, N4}N;
    printf("N1 %d \n", N1);
    printf("N2 %d \n", N2);
    printf("N3 %d \n", N3);
    printf("N4 %d \n", N4);        
    return 0;
}

I can achieve behavior of enumeration with define keywords

#include<stdio.h>

#define N1   0
#define N2   1
#define N3   2
#define N4   3

int main (){
    printf("N1 %d \n", N1);
    printf("N2 %d \n", N2);
    printf("N3 %d \n", N3);
    printf("N4 %d \n", N4);
        
    return 0;
}

My question was that define and enum are two different keywords. And both of have their own importance and specialty and I am missing the special purpose. When and where, which keywords should I really need to use

In your #define versus enum example, one key piece you are missing is that an enumerated type is a new type, whereas a #define is just some text replacement that is taken care of by the preprocessor. Since an enum is a type you can create variables of that type. The compiler can also do type checking for you, though C is admittedly not nearly as good at this as other languages (though some compiler extensions are pretty thorough).

 

Or not.

I see you've referred back to a thread that's all about assembly language programming, not compiled code. Of course in assembly there's no such thing as a switch-case construction, so you haven't demonstrated much! I wouldn't claim that every compiler will avoid jump tables every time, but I think it's clear that when people create compilers, they usually play safe and just use a sequence of tests.

 

but I think it's clear that when people create compilers, they usually play safe and just use a sequence of tests.

I have worked on many compilers. All used a jump table to implement some switch statements. Some used four or five different code patterns based on the details of each switch statement.

Bob

 

I see you've referred back to a thread that's all about assembly language programming, not compiled code. Of course in assembly there's no such thing as a switch-case construction, so you haven't demonstrated much! I wouldn't claim that every compiler will avoid jump tables every time, but I think it's clear that when people create compilers, they usually play safe and just use a sequence of tests.

My intention was to show that it is possible to avoid some -- if not all* -- of the drawbacks you mentioned re a C switch statement in PICs using jump tables. Of course, one would have to write or modify a compiler in order to compile a C switch statement into such an assembly construct. If I was in the business of writing compilers, I'd consider this as a possible optimization for the compiled code.

*With just a bit more code, I could modify my assembly code to allow for non-sequential and/or out of order case values.

 

Oh, I agree it can be done, and I've done it myself, also in assembly. I'd have thought that by applying a few rules, a compiler could create jump tables for at least some situations--cases tested for are mostly consecutive numbers, for instance, and it wouldn't be difficult to rearrange them if the original code wasn't written that way. But it's not that hard to toss in a few lines of assembly if we really want to make it happen.