0

I know what the basic idea there is, but I was thinking, and I realized, that it would therefore take MORE characters for a switch statement than for a bunch of if statements.

Since an if statement has 7 characters (not including the variable name, nor what it is being compared to, nor the code), while the switch statement has 9 characters (same thing), because of the word "break", and even without it, the word "case:" is 5 characters, compared to 7 from the if statement, so it isn't that much better than an if statement!

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
noah
  • 183
  • 2
  • 8
  • 2
    Because C++ was not written to conserve characters. See http://www.golfscript.com/golfscript/ – Daniel Aug 23 '10 at 01:04
  • 1
    I wouldn't close this. This is a legitimate question: what are the advantages of having fall-through be the default in a `switch`, and why do they outweigh the verbosity? – Tyler McHenry Aug 23 '10 at 01:05
  • 2
    The character count is the biggest issue? What happens when you accidentally forget a `break`? Worse, what happens when you try to have some "fall through" in a case, and no one can figure it out, adds the `break` and destroys the logic? Don't these have meaningful impact when the number of characters is irrelevant? – S.Lott Aug 23 '10 at 01:06
  • The `break` instruction has a purpose, in a `switch` statement; try removing `break`, and you will see the effect. – apaderno Aug 23 '10 at 01:06
  • 2
    It is indeed a valid question. Why doesn't the `switch` statement use a `continue` statement like the loops? In many cases that would be beneficial. – Wolph Aug 23 '10 at 01:10
  • 3
    The subject suggests a valid question, but the actual question is waaaay too focused on character count. – Ben Voigt Aug 23 '10 at 01:16
  • Duplicate of [Why was the switch statement designed to need a break?](http://stackoverflow.com/questions/252489/) which is tagged [c], but c++ inherited the behavior. – dmckee --- ex-moderator kitten Sep 08 '10 at 19:48

9 Answers9

16

So that you can do things like

switch (toupper(ch))
   {
   case 'A':
   case 'E':
   case 'I':
   case 'O':
   case 'U':
      bVowel = true;
      break;

   default:
      bVowel = false;
      break;
   }
franji1
  • 3,088
  • 2
  • 23
  • 43
3

I think it's a misfeature since the ability to fall through to the next block is confusing and error-prone. The common case of wanting to match multiple options would be better written:

switch (expression) {
   case 1, 7, 9:
      do something;
   case 2, 8, 10:
      do something else;
}

This wasn't an option for C++ though, since the language was designed to be relatively backwards compatible with C.

  • That syntax is nicer in that case, but there are still some things that you can do with switch the way it is that you can't do like that. For example, suppose case 3 does C, case 2 does B and C, and case 1 does A, B, and C. This is elegant with fall-through, but impossible with the syntax you propose (without repeating B once and C twice). I suppose the bottom line might be flexibility -- allowing fall-through is the maximally flexible way to provide switch (although whether fall-through should be implicit or explicit is another question). – Tyler McHenry Aug 23 '10 at 01:23
  • Agree with you,+1, but probably need a keyword to fall through when needed as @Tyler points out. – ergosys Aug 23 '10 at 02:03
3

There are many important factors other than character count:

  • switch statements evaluate the expression once, whereas lazy coding of an if statement may request repeated evaluation... undesirable if expensive or having side effects
  • whether cases should fall through or need breaks varies per usage: you can save a lot of characters if the same action applies to many cases
  • optimisers should make switch statements at least as efficient as an if/else if/else chain IN EVERY USAGE, and for many usages it can be far more efficient (e.g. lookup value in an array to switch to the desired behaviour/result, build a binary search)
  • switch statements better document the single value deciding the flow, whereas if/else-if/else require the programmer to check each expression separately
Tony Delroy
  • 102,968
  • 15
  • 177
  • 252
1

You have a very odd way of deciding which is "better". In general "easier to think about" is a much more useful test than "shorter".

Ultimately, this is what the designers of the C language decided was the way that provided the best mix of readability and ease of compilation.

With any decent optimizing compiler, there's not likely to be much difference in the final generated program.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
1

A compiler can come up with various different strategies for generating machine code for a switch statement, namely:

  • A lookup table, when the values tested for are very close together
  • Binary search, when there are a lot of values
  • Code that looks just like an if-then.

These days, the compiler may be smart enough to make such optimizations on a bunch of if statements, but that surely wasn't the case when the language was designed, and the switch statement puts all of the information right there for the compiler to look at and decide what code to generate.

Ken Bloom
  • 57,498
  • 14
  • 111
  • 168
0

  1. Every "if" statement has to be evaluated at runtime. This could depend on compiler optimisations.

  2. Switch statements are more efficient in terms of evaluating the expression for each case as I understand it.

  3. If you don't add the break the switch statement will continue down and could execute further cases. eg the default statement as well. eg if/else

  4. I prefer if/else if /else because they are harder to muck up if you forget the break. They take up less room, and they are more common with other coders. But you can make a switch statement look pretty.

John Ballinger
  • 7,380
  • 5
  • 41
  • 51
  • Every switch statement member is also evaluated at runtime. What do you think is going on, magic? – Billy ONeal Aug 23 '10 at 02:02
  • not if it is 1==1 The compiler will default this to true. Thanks for being so polite. – John Ballinger Aug 23 '10 at 02:09
  • @billy, also see Ken Blooms statement below about how a compiler can build hash tables to quickly jump to cases quickly. – John Ballinger Aug 23 '10 at 02:17
  • @John: I'm not going to sugarcoat things when I see that they are blatantly wrong; sorry if my bluntness sounds rude, but it is what it is. My point is that yes, there are some cases where a compiler can speed lookups in a switch. That said, this is not always the case -- there's no magic thing the compiler does that makes the branches go away. Also, unless you have several hundred branches generating code that operates just like the IF/ELSE is going to be faster anyway. – Billy ONeal Aug 23 '10 at 02:30
  • I love it how this question has now been closed due to "Subjective" and "Argumentative" – John Ballinger Aug 23 '10 at 04:00
0

For a switch statement, a compiler could, for instance, make a map of case values and goto addresses and do an optimised lookup, as opposed to just going through all the 'if' checks.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
matt
  • 4,042
  • 5
  • 32
  • 50
0

It's so that things like Duff's Device can work.

Community
  • 1
  • 1
Eclipse
  • 44,851
  • 20
  • 112
  • 171
  • 4
    I think that was more of an accident than anything else. And I think your getting a sense of dark amusement pointing a clear newbie at a very bad programming practice. :-) – Omnifarious Aug 23 '10 at 01:26
  • Well, yes and no. It does indicate how switch and case statements in C and C++ are closely related to goto statements and label. When you think of `switch()` as a sort of calculated goto, and `case ` as a type of label, then the reasons for `break` become apparent. – Eclipse Aug 23 '10 at 04:40
  • I had thought that the switch statement was for being lazier when you have a whole lot of comparisons to make – noah Sep 08 '10 at 00:57
0

C was designed to be easy to compile. Many aspects of the language which were pretty terrible, such as the old style parameter passing, have been successfully deprecated. Case statements were designed so that case labels didn't have to generate any code, but could be handled similarly to "goto" labels. Nowadays there's no particular need for the language to be easy to compile, but it would be impossible to change the way 'switch' statements work without breaking a lot of code.

supercat
  • 77,689
  • 9
  • 166
  • 211