Is there any problem with having a switch case consisting only of 'break;' if it is intended that this value should do nothing?

switch (x)
{
     case 0:
            DoSomething0();
            break;
     case 1:
           break;
     case 2:
           DoSomething2();
           break;
}

 

No

 

Without the break; in place, case 1: and case 2: would both perform the same function, It is both syntactically and semantically correct.

 

You could be lazy and skip the "break" after case 0. Then case 0 executes DoSomething0() and falls into case 1, which doesn't do anything, but has the break.

 

I think an optimizing compiler would have a single branch instruction for the two break; statements. Putting the redundant break is a safer way to write code.

 

Is there any problem with having a switch case consisting only of 'break;' if it is intended that this value should do nothing?

switch (x)
{
     case 0:
            DoSomething0();
            break;
     case 1:
           break;
     case 2:
           DoSomething2();
           break;
}

@AlbertHall
No, there is absolutely nothing wrong with doing that. Optimizer will take care of it, if you have optimization turned on. If there are more than 1 possibility that you don't wish handled you can do this as well:

switch(x)
   {
   case 0:
   case 2:
      DoSomething();
      break;
   };

or:

switch(x)
   {
   case 0:
   case 2:
      DoSomething();
      break;
   default:
      // do nothing
      break;
   };

 

Do not omit the break statement when no action is desired.

switch(x)
{
   case 0:
      // do nothing
   break;
   case 2:
      DoSomething();
   break;
   default:
      // do nothing
   break;
};

 

OK, thanks all. I have a program doing strange things and I couldn't find an example like this, but it seems I need to look elswhere.
It is difficult to debug as it is two embedded systems which are supposed to be talking to each other.

 

You could be lazy and skip the "break" after case 0. Then case 0 executes DoSomething0() and falls into case 1, which doesn't do anything, but has the break.

And laziness invites disaster.

At some point you are going to decide that you want to do DoSomething1() and then every time x=0 you do DoSomething0() -- arm the explosives -- followed by DoSomething1() -- detonate the explosives if armed.

Only omit the break if the intention is for the actions of one case is to flow into the next case -- and document it as such otherwise someone looking at it later (including the original programmer) is likely to "spot the error" and fix it.

 

Only omit the break if the intention is for the actions of one case is to flow into the next case -- and document it as such otherwise someone looking at it later (including the original programmer) is likely to "spot the error" and fix it.

Are you sure? My experience is only with Swift, a descendant of C. Only the relevant case will execute and that seems like the whole point of the switch. The only reason to use a break is that Swift requires at least one executable line per case. It allows you to differentiate a case and do something different than the default.

var x = "a"
switch x {
case "a":
    print("here is A")  // Prints
case "b":
    print("here is B")  // Does not print
case "c":
    break
default:
        print("here is X")
}

 

C was designed that why so we could have

dsend(to, from, count)
char *to, *from;
int count;
{
    int n = (count + 7) / 8;
    switch (count % 8) {
    case 0: do { *to = *from++;
    case 7:      *to = *from++;
    case 6:      *to = *from++;
    case 5:      *to = *from++;
    case 4:      *to = *from++;
    case 3:      *to = *from++;
    case 2:      *to = *from++;
    case 1:      *to = *from++;
               } while (--n > 0);
    }
}

Duff's device.

C is a clean interface to standard assembly idioms.

 

Are you sure? My experience is only with Swift, a descendant of C. Only the relevant case will execute and that seems like the whole point of the switch. The only reason to use a break is that Swift requires at least one executable line per case. It allows you to differentiate a case and do something different than the default.

The TS is specifically asking about C. Other languages have different rules for switch() statements in an effort to protect programmers from themselves.

Java, for instance, I believe (it's been awhile) only allows flow-through on empty cases. Other languages don't allow it at all. They are trying to turn common logic errors into syntax errors.

The C language takes a fundamentally different position -- if you are programming in C they assume that you know what you are doing and that if there is a way to compile what you have written, it will do it. C gives the programmer plenty of rope with which to hang themselves, but it also gives the programmer the tools needed to squeeze performance out of their code.

 

C was designed that why so we could have...

Soooo, no break statements?

 

Soooo, no break statements?

The need for explicit breaks (exits from execution flow) statements like in assembly.

 

The TS is specifically asking about C. Other languages have different rules for switch() statements in an effort to protect programmers from themselves.

Yup. Per Swift docs:

No Implicit Fallthrough
In contrast with switch statements in C and Objective-C, switch statements in Swift do not fall through the bottom of each case and into the next one by default. Instead, the entire switch statement finishes its execution as soon as the first matching switch case is completed, without requiring an explicit break statement. This makes the switch statement safer and easier to use than the one in C and avoids executing more than one switch case by mistake.

 

Soooo, no break statements?

Not if you don't want them.

The break statement is a non-structured programming statement, like goto and continue. It simply performs a goto to the first line of code after the enclosing loop or switch construct.

 

Yup. Per Swift docs:

Safer and easier. The rationale for most limitations in life.

 

Safer and easier. The rationale for most limitations in life.

Love and marriage.