The Lounge - CodeProject

BillWoodruff2-Aug-17 22:10

2-Aug-17 22:10

One of the "beauties" of the stock C# switch statement was that using integer case qualifiers it compiled to a mean and lean jump-table in CIL. I assume it still does; have yet to see any performance comparisons of use of the new features and other techniques for switch-a-roo.

I like the new features.

«Differences between Big-Endians, who broke eggs at the larger end, and Little-Endians gave rise to six rebellions: one Emperor lost his life, another his crown. The Lilliputian religion says an egg should be broken on the convenient end, which is now interpreted by the Lilliputians as the smaller end. Big-Endians gained favor in Blefuscu.» J. Swift, 'Gulliver's Travels,' 1726CE

Re: switch statement

kalberts4-Aug-17 0:36

kalberts

4-Aug-17 0:36

Note that this is not at all set by the language defintion, but 100% decided by the compiler writer. I have seen compilers (not C#) that generate completely different code depending on the optimization switches: If you optimize for speed, and the case alternatives are sparse, you may end up with a huge jump table. If you optimize for code size and the number of specific cases is small, it might compile like an if ... elseif ... elseif ... When you switch on strings, hash methods are sometimes used to reduce the number of string comparisons that must be done.

Compilers may try out several different methods of compiling a switch statements, and assign scores to each alternative based on the compiler options, such as optimization and target architecture. The one with the highest score wins, and is passed on to later compiler stages. This sure slows down compilation, but is generally worth it.

A small sidetrack, but closely related: Contrary to common belief, modern standards for sound and image processing, such as MP3 and JPEG, does not specify how the compression is to be done, only how a compressed file is decompressed. A good compressor may try out a handful of different ways to compress the original (sometimes varying wildly in compressed encoding), decompress according to the standard and do a diff with the source material. The alternative with the smallest diff result is selected. (Or, the size of the diff result gives that alternative fewer or more points on the scoreboard, together with e.g. compressed size). The compress-decompress-diff-evaluate sure takes CPU power, but today we have plenty of that, at least for sound and still images.

Re: switch statement

Clifford Nelson4-Aug-17 4:16

Clifford Nelson

4-Aug-17 4:16

I think that is the reason that it took so long to upgrade the switch statement. I would expect that you are right an it still with do that. Of course could also do a string which would be a little more complex, and I am sure there is a different implementation for a int and string. swtich statements are a bad smell, so I look to see if there is a better implementation than a swtich. Smile | :)

Re: switch statement

kalberts2-Aug-17 22:47

kalberts

2-Aug-17 22:47

Why didn't they make it multivariable as well, like in CHILL?

switch (a, b, c) {
(1, 'a', 4.3): ...code;
(2, 'A', 0.0): ...code;
(2, ELSE, pi): ...code;
(3, 'C', *): ...code;
ELSE: ...code;
}

* for a value means "don't care". ELSE for a value means "any value not used in any other switch alternative for this variable.

Yes, you CAN make it very messy if you exploit the flexibility for all that it is worth. But a diciplined use can be far more readable than a 20-way switch, each alternative with a 7-15 way (varying among the 20) switch, each of those again with a 2-15 way (varying) switch. Then I'd rather prefer the single, clean, 3-dimensional switch.

Re: switch statement

Clifford Nelson4-Aug-17 4:18

Clifford Nelson

4-Aug-17 4:18

Did not have exposure to that. Interesting. Not sure how often it would be useful, but if it helps....

Re: switch statement

kalberts4-Aug-17 4:56

kalberts

4-Aug-17 4:56

The CHILL language, providing this, was essentially developed to program network switches. If you have been much in contact with communication guys, you have certainly noted that they love designing protocols as state machines:

Any entity is at any time in one of a limited number of states. Whatever happens in the interface is modeled as an atomic event; the event ID being one of a limited set of values. The processing of the event depends on the current state and the event ID. Processing is (conceptually) atomic, and changes the entity state into a new value. So a very common usage would be like (in quasi-C syntax, Chill was somewhat different)

switch (state, eventID) {
(disconnected, setupReq): ... code to handle a call setup request...
(transferMode, dataPacket): ...
... more state/event combinations, with their specific handling ...
(transferMode, ELSE): ... error hadling, protocol error, not allowed in transferMode state...
ELSE: ... general error handling for illegal event in current state, not treated as a specific case...

Now, some protocols are so complex that a "pure" state machine would end up with thousands of states. So the protocol spec defines from one up to a small handful of state variables, which may be thought of as sub-states in most cases (not always, but "sort of like"). So you could add one or more of those state variables as the third switch field, if they should lead to distinctly different handling. (For many switch cases, the switch label would be "Don't care" for that state/eventID combination.)

So, for protocols defined as state machines, the multidimensional switch statement is a perfect match.

I love that kind of protocol specification! It is terse, lucid, unambiguous, and most of all: It pinpoints all protocol error situations and makes it very clear to you where you should define an error handler, and the reasons for raising this error condition.

Welcome to the Lounge