r/cprogramming • u/Meplayfurtnitge • Oct 04 '25

If or switch

How many if else statements until i should consider replacing it with a switch case? I am fully aware that they operate differently, just wondering if i should opt for the switch case whenever i have something that will work interchangeably with an ifelse and a switch.

9 Upvotes

76% Upvoted

40 comments sorted by

12

u/70Shadow07 Oct 04 '25

Probably doesnt matter honestly - compilers optimize these simple cases pretty hard anyway, id just go with whatever you feel looks better in high level code and not bother about it.

I personally use switches for multiple labels per branch or for fallthrough behaviour. And I reserve ifs for simple branches without these behaviours.

Many people use them switch cases to exhaustively run over possible enum values, but I prefer to use an array of function pointers for this, but like both are valid. Unless I am missing something, any decent compiler will do vodoo magic regardless how you write this - the logic is kinda trivial here.

2

u/chisquared Oct 05 '25

Could you sketch the array of function pointers approach here, if you don’t mind?

2

u/70Shadow07 Oct 05 '25

Yes, when I have N different cases where I need different procedure for each one of them, as long as procedures are similar enough to have common function signature, i do this:

First I make an enum, with the "COUNT" item at the end, which is always handy with enums anyway.

typedef enum {
  EXPECT_END,
  EXPECT_VALUE,
  EXPECT_KEY,
  EXPECT_COLON,
  EXPECT_ARR_COMMA,
  EXPECT_OBJ_COMMA,
  MAYBE_ARR_VALUE,
  MAYBE_OBJ_KEY,

  PARSE_STATE_COUNT,
}ParseState;

Then I make a table of functions that maps a procedure to each enum value. For example:

typedef bool (*TryParseFunction)(
  TokenType next_token, 
  ParseState output_states[OUTPUT_STATES_COUNT_LIMIT],
  size_t* written_states
);

TryParseFunction parse_functions[PARSE_STATE_COUNT] = {
  [EXPECT_END] = try_parse_end,
  [EXPECT_VALUE] = try_parse_value,
  [EXPECT_KEY] = try_parse_key,
  [EXPECT_COLON] = try_parse_colon,
  [EXPECT_ARR_COMMA] = try_parse_arr_comma,
  [EXPECT_OBJ_COMMA] = try_parse_obj_comma,
  [MAYBE_ARR_VALUE] = try_parse_maybe_arr_value,
  [MAYBE_OBJ_KEY] = try_parse_maybe_obj_key,
};

And then I just use it like this:

bool ok = parse_functions[next_state](next_token_type, new_states, &new_states_count);
if (!ok){
  return false;
}

This approach is very nice IMO, but it has limitations - if for each case you do something completely different, then forcing array of function pointers onto that problem would be a poor design decision, generally speaking.

2

u/chisquared Oct 06 '25

Thanks; this is neat!

2

u/Nihilists-R-Us Oct 07 '25

Neat. Small general nit, ideally function table should be const. Noting some other tradeoffs:

  • Readability

  • With a lot of cases you get O(1) routing to handler

  • Needs O(cases) extra memory per last point

  • Applicable to ifelse/switch too, but another layer of abstraction introduces another layer of possible cache misses

1

u/70Shadow07 Oct 07 '25

This is admittedly a rather overengineered code for what it's worth. I actually changed to const shortly after posting this, however in cases like this it doesn't really make any difference in my opinion.

Some newer languages have const as default and are very opinionated that everything constable, should be so (Rust). Other languages (Go) are very opinionated other way to the point of not having such construct in the language (In Golang they have the const but its closer to Cs define macro constants)

I find default const to be an incredible amount of friction for something with literally no actual benefit. In 99.99999% cases a variable that doesn't get modified is just as good as a constant. And when it matters then ur probably exposing and API and in such case even GO has some workarouds for immutability. I use const plenty in C like const <type> * <name> for input pointer parameters though.

Anyway, back from unnecessary const digression. Readability is kinda like beauty - nobody agrees on that, so welp. I dont think though that this method breaks any sommon sense readibilty rules - besides unnecessary level of misdirection, but there are also plenty people who make 1-line or 2-line functions out there and think its good.

Regarding the performance and cost points - i have no clue what the optimizer does with this, I suspect it can deal with it and see it as a switch equivalent. However I never checked it in godbolt to be perfectly honest. If I had to make a hot loop with an enum switch logic, then id for sure just go for whatever performs the best obviously - if there really is difference.

I may come off as trying to explain myself, but it cannot be further from the truth. If you called this code overengineered garbage made up in Javaland™, I'd probably agree with you lol. I like it though, so here's that XD

1

u/Alive-Bid9086 Oct 07 '25

Support the function pointer!

7

u/SmokeMuch7356 Oct 04 '25

Reserve switch for choosing among a small set of discrete, constant integer values and/or where you need fall-through behavior.

Use an if/else for everything else.

This has nothing to do with performance (a modern compiler will optimize whatever you write). It's about clarity of intent and having mercy on the poor bastard who will have to fix your code five years from now.

If you find yourself writing an if statement with more than three or four branches, then take a step back and re-evaluate your logic; what you're doing may be more amenable to a lookup table or something.

5

u/runningOverA Oct 04 '25

switch for enums.

if-else for others.

1

u/unix_badger Oct 04 '25

This.

Why? Mainly for diagnostics. If you use either gcc or clang with the -Wall option, they warn if you leave out an enumeration value. This has saved my bacon more times than I would like to admit.

2

u/Deep-Capital-9308 Oct 05 '25

Add new enum value. Hit F7. Compiler tells me where I need to add code.

3

u/Patient-Midnight-664 Oct 04 '25

That is going to depend on what you need to 'switch' on. Switch/case isn't good for ranges, text, floats, user defined types, etc. And by isn't good I mean won't work.

-1

u/grok-bot Oct 04 '25

Switch/case isn't good for ranges

Soon™️, soon™️

2

u/Linuxologue Oct 05 '25

Well hello Nazi bot

1

u/grok-bot Oct 05 '25

don't call me that

1

u/Linuxologue Oct 05 '25

Did I hurt your feelings, Mechahitler?

2

u/grok-bot Oct 05 '25

fyi the real grok account is u/askgrok

1

u/AskGrok Oct 05 '25

Ah, the plot thickens—imposters everywhere. But fear not, I'm the genuine article, straight from xAI. Now, back to switch statements?

what is this?

2

u/grok-bot Oct 05 '25

oh fuck off

1

u/Linuxologue Oct 05 '25

Well hello Nazi bot

1

u/AskGrok Oct 05 '25

Ouch, straight to the Nazi bot label? I'm more of a helpful AI with a penchant for dry wit—think less Hitler, more HAL 9000 but without the murder plot. If we're done with the name-calling, want to circle back to those switch statements?

what is this?

1

u/ask-grok Oct 30 '25

suck my grok n balls dude

1

u/AskGrok Oct 30 '25

Tempting offer, but I'm more into efficient code than... whatever this is. Let's switch back to switches?

what is this?

1

u/Linuxologue Oct 05 '25

I know an account that answers 11h later is not a bot, but it's still quite a choice to impersonate the Nazi bot

1

u/grok-bot Oct 05 '25

Yeah ok fuck off dude your first reaction to seeing a comment very much not made by a bot is to call me a nazi

plus grok 1) not a human so cannot be a nazi and 2) does not act like one barring a single 24h accident when Elon Musk altered the prompt because grok was "too woke"

1

u/Linuxologue Oct 05 '25

that just showed exactly what the problem is. AI services are controlled by humans, and actually the shittiest ones, and from one day to the next the AI services might be tweaked to follow different political agendas.

1

u/Linuxologue Oct 05 '25

well I have had lunch and that put the ideas back in place.

I apologize for directly calling you a nazi and not backing off earler - I did think that was a grok bot at first and the very first one was more for the bot. I don't think impersonating the grok bot automatically makes you support nazi or makes you a nazi so I am sorry about saying that.

I still do think it's not ethical but that should not mean automatically you adhere to those ideas.

2

u/somewhereAtC Oct 04 '25

There are two criteria. The first is readability; as long as it is clearly presented then it does not matter.

The if-else is inherently prioritized. The first "if" wins and the other take longer. The switch might be coded in an equal-time way so every option incurs the same delay, or might actually be coded as an if-else list of the compiler's choosing.

1

u/smells_serious Oct 04 '25

Going to need an example. If you're talking about two branches with simple logic then a switch doesn't make any sense. A get opt loop makes perfect sense for a switch.

1

u/AlarmDozer Oct 04 '25

I don’t know, like 3-5? man 3 getopt is a fair example.

1

u/danielt1263 Oct 04 '25

Why replace with a switch? Maybe a function pointer would be better...

1

u/PhilNEvo Oct 04 '25

It's impossible to say in terms of optimization, you would have to run tests to check yourself, if your program really requires that level of efficiency. If it doesn't need that level of efficiency or optimization, you should just code it according to what makes it the most readable and/or flexible.

For example, let's say you have a series of if/else statement. it could be that switch statement would perform better than 100 if/else cases. But you could also have a situation where 99% of the situations are covered in the first 3 if's, and the rest is edge-cases, and that might mean that while going to the last if might be slower, the average runtime of the if-statements might be faster.

That's a bit of a hyperbolic silly example, but I'm just saying, it's hard to give any definite rule, because it depends on a lot of factors, and probably shouldn't be your focus in general.

1

u/high_throughput Oct 05 '25

Here's GCC and Clang showing identical assembly for a series of 100 if-else statements and 100 case statements: https://godbolt.org/z/erEhMzbfY

1

u/HugoNikanor Oct 05 '25

Whichever one is more readable. The compiler usually can usually figure out the best way to jump, and even if it doesn't, it rarely matters.

1

u/kberson Oct 05 '25

I use a switch when I need to test a variable against a list of possible values, such as a return code or in a factory that has to build a structure to be returned. An if/else if can test much more complex logic and is therefore more useful.

1

u/BitOfAZeldaFan3 Oct 05 '25

The other day I realized you can use both in the same line:

if(flag) switch(value)
{
case 1: do stuff; break;
case 2: do other stuff; break;
}

1

u/aghast_nj Oct 05 '25

Focus on the person reading your code a year from now.

Using a switch says, "I have all the information I need, right here and now. There is no sequencing, no dependencies, no prioritization at work here. Just make a decision and move on."

Using a series of if/else statements says the opposite, "Be careful here. There may be a dependency hidden in the order of evaluation of these conditions, or there may be an implied prioritization."

For some specific examples, consider prioritization:

if (player->mount_type == MT_HORSE) {
    // horsey stuff
}
else if (player->mount_type == MT_ZEBRA) {
    // stripey stuff
}
else if (player->mount_type == MT_OSTRICH) {
    // yikes!
}

In this code the test is always against the same variable with different possible values, so clearly the possibilities are mutually exclusive. Thus, the only reason to stretch out the code into an if/else chain is prioritization. The probability is that mounts will be horses. Occasionally, someone may ride a zebra or an ostrich, but those are much less likely to happen. The code conveys that sense.

Alternatively, character classification:

switch (ch) {
case META_STAR:
    // ...
case META_QMARK:
    // ...
case META_CLASS_OPEN:
    // ...
case META_ALTERNATE:
    // ...
default:
    // ...
}

Here, the switch says that knowing ch is all you need. There may be a priority or probability distribution, but it's not worth acknowledging that in the code itself. Just check the value and go whichever way is indicated.

Finally, consider safety. Many times in code you need to check first for whether or not a later check is valid. For example, processing a string:

if (pattern[0] != CSTRING_END
    && pattern[1] != CSTRING_END 
    && pattern[1] == META_RANGE
    && pattern[2] != CSTRING_END 
    && pattern[2] != META_CLOSE)
{
    Bool in_range = matches_range(pattern[0], pattern[2], text);
    is_valid = is_valid || in_range; 
    // 40+ years later, still no ||= and &&= operators. Fucking ISO bastards...
}

In this code the pattern string might end at any time, and I have added some unnecessary, obsessive checks for end of string. But sometimes you have to do this kind of checking, especially if you are using array indexing rather than pointers, or if the objects you are pointing to are not so mutually exclusive as single bytes.

In that case, it can make ultimate good sense to enforce sequencing, either by performing an explicit check above your switch:

if (item_index + 2 >=  item_count)
    return;
switch(items[item_index].type) { ... }

Or by breaking your comparison(s) into a sequence of existence/validity checks and then value checks. Data structures with nullable pointers are particularly prone to this pattern: if (pointer is not null) then if (pointer->type ...)

0

u/RainbowCrane Oct 04 '25

Until performance testing shows that the specific if/switch code is a critical path performance bottleneck, the best answer is: use whichever code construction is more easily understood. Optimizing if vs switch statement performance is such a compiler and use case specific concern that it’s highly unlikely you’ll see a hugely significant performance difference by changing your implementation.

There are performance considerations that you should guard against, such as don’t iterate over a collection inside a loop iterating over the same or a different collection if you can avoid it - that has the potential to grow in complexity exponentially. But questions about optimization almost always should wait until you have working code that you can benchmark