C#: Throwing warnings?

[iago]

No, an if/else tree evaluates the conditions in the order they appear. A switch table with constant base types as its cases uses a jump table, which more appropriate for this case.

In any event, for this particular example, where this code is executed once per execution, it is hardly worth arguing over. As a matter of principle, however, you should at least be aware of how each one works.

I don't think you quite understand the principle behind the different constructs.

The only reason your statement holds true is because switches are forced, by the browser, to have different values. But that's just a side effect of its structure, not the reason for it.

[Joe]

I love how horribly off-topic this became. It makes me fuzzy and gleeful inside.

[Camel]

Joe: since your question was already answered, I wouldn't consider this going off topic.

The only reason your statement holds true is because switches are forced, by the browser, to have different values. But that's just a side effect of its structure, not the reason for it.

I'm not sure what your point is. Can you elaborate?

All I'm trying to say is that, where a switch can be used, and where there are more cases than double the number of operations it takes to evaluate input-to-address of the jump table, it's exclusively faster to use a switch construct, except with cases where my assumptions (such as the way a switch reduces to a jump table) don't hold true, and where the first options in the if/else tree are to occur more often than the latter options.

That is one of the longest non-run-on sentences I've ever written.

[MyndFyre]

except that an optimizing compiler would choose whether to use a jump table or explicit per-case evaluation regardless of whether you use if-elses or switch or even nested ifs. Your statement is flawed; iago is correct in stating that you seem to not understand what it's for.

[Camel]

The "let the optimizer figure it out" defense is invalid, regardless of whether you are correct or not. It takes a fool to assume that a compiler will have an optimizer, or that it will behave in any specific way. Even so, choosing an if/else tree where it is logical to use a switch() construct will not help the compiler figure out how to optimize it, because a switch() construct's purpose is more obvious than a tree of if/else statements.

If you read what I posted, you'll see that I said my assumptions include that switches reduce to jump tables, while if/else trees do not. This assumption is based off of several experimental benchmarks I did in which agreed with me. It seems to me that you are trying a little too hard to read between the lines, when in reality I do not speak in tongues.

[iago]

Joe: since your question was already answered, I wouldn't consider this going off topic.

The only reason your statement holds true is because switches are forced, by the browser, to have different values. But that's just a side effect of its structure, not the reason for it.

I'm not sure what your point is. Can you elaborate?

All I'm trying to say is that, where a switch can be used, and where there are more cases than double the number of operations it takes to evaluate input-to-address of the jump table, it's exclusively faster to use a switch construct, except with cases where my assumptions (such as the way a switch reduces to a jump table) don't hold true, and where the first options in the if/else tree are to occur more often than the latter options.

That is one of the longest non-run-on sentences I've ever written.

It seems that you changed your story from your other posts. Suddenly, the point is to use a jump table, not to force mutual exclusion. Nice try, though!

[Camel]

If you thought I cared about mutual exclusion, then clearly I mislead you in my other posts. From my first response to MF, I can see how you could have made false assumptions about what I meant, but in my second post I pointed out that an if-else tree is inherently less efficient than a jump table for states that have many transitions, so I'm not sure how you could possibly have been mislead.

If you think about an if-else tree that does not enforce mutual exclusion analytically, in terms of states and transitions, you would not be describing a single state with many transitions, you'd be describing multiple states with multiple transitions. Some of those states might be unreachable due to circumstance, or even have no transitions whatsoever (consider: if(false){...} for example).

I could just as well argue that the mutual exclusion rule is a product of the way jump tables work, because the switch/case construct was designed as an aide for the compiler. The rules which apply to its manifestation in the code layer are a product of the way it is implemented in the assembly/bytecode layer.

Any decision of the compiler to replace a switch/case construct with if-else-style assembly/bytecode, and any decision of the compiler to replace an if-else tree construct with a jump table is an optimization, which is not something you can rely on in any condition where you care that there is a difference.