JSFX: Switch statement.

[sai'ke]

I noticed that a fair amount of time in some of my more complicated plugins that have a lot of selectable options is being spent in linear chains of if-statements.

Since we don't really have dynamic function calls (like function pointers or something similar), I kind of rely on this pattern a lot.

I noticed that converting the following linear chain

(foo == 1) ? (
) : (foo == 2) ? (
) : (foo == 3) ? (
) : (foo == N) ? (
);

into a hierarchical one conferred a large performance boost:

(foo < 25) ? (
  (foo == 1) ? (
  ) : (foo == 2) ? (
  ) : (foo == 24) ? (
  )
) : (
  (foo == 25) ? (
  ) : (foo == 25) ? (
  ) : (foo == 26) ? (
  ) : (foo == N) ? (
  )
);

This made me wonder whether it'd be possible to have something like a switch statement in JSFX that just acts like a jump table to the active code.

I do realize that I'm probably using JSFX a bit beyond the scope of what it was really intended for though, so it's cool if this is out of scope. Just thought that if it was easy to do it'd be cool. If not, the hierarchical if-statements work well enough

[mschnell]

Yeah ! C++ would be really nice !
ROFL

[Justin]

Hmm, it would probably be possible to add to EEL2 a keyword with usage of something like:

switch(x, 
  0: code,
  1: code,
  2: code,
 [ default_code]);

the caveat would be that the 0/1/2 values would need to be constant values. Probably would be most useful if x was rounded to the nearest integer, too?

[souk21]

I like the idea !

switch(x,
  0: (
    //Some
    //Multi
    //Line
    //Code
  ),
  1: (
    //Some
    //Multi
    //Line
    //Code
  ),
  (
    //Some
    //Multi
    //Line
    //Code
  )
);

vs

x == 0 ? (
  //Some
  //Multi
  //Line
  //Code
) : x == 1 ? (
  //Some
  //Multi
  //Line
  //Code
) : (
  //Some
  //Multi
  //Line
  //Code
);

The switch is a bit more readable to me.
Would that come with the performance improvement described by sai'ke ?

[sai'ke]

Originally Posted by Justin

Hmm, it would probably be possible to add to EEL2 a keyword with usage of something like:

switch(x, 
  0: code,
  1: code,
  2: code,
 [ default_code]);

the caveat would be that the 0/1/2 values would need to be constant values. Probably would be most useful if x was rounded to the nearest integer, too?

Sounds great to me! Would the code blocks in that case be allowed to be multi-line if enclosed by parentheses (the way souk21 suggests), or would they have to be single lines?

And yeah, I was assuming that the cases would have to be fixed, but they would be for the typical algorithm selection use case.

And yes on the rounding. Though I'm unsure whether nearest or truncation is more desirable. From other languages, I'd usually expect the latter, but I think you should probably pick what you think is most in line with what is typical in JSFX. For the use cases I have in mind it wouldn't make a difference which one you'd pick I think.

[juan_r]

I'm having trouble writing a MIDI JSFX because I'm missing break or return--a way to exit a loop prematurely. Or a continue statement to cut it short if it's substantial in size.

So here's a similar request I just made for these statements: https://forum.cockos.com/showthread.php?t=266629

[mschnell]

In case you did not already find a solution: a (additional) variable needs to be checked in the loop statement to allow for "break" by setting that variable within the loop.
-Michael

[juan_r]

Of course, but you either place a check every other instruction, or wait for the current iteration to end (if checking, say, in the head of the loop).

[mschnell]

Yep. In certain cases you additionally need to "?" check that variable to jump over the rest of the loop.

A "break" instruction might be slightly faster in certain cases.
-Michael

[juan_r]

Originally Posted by mschnell

Yep. In certain cases you additionally need to "?" check that variable to jump over the rest of the loop.

A "break" instruction might be slightly faster in certain cases.
-Michael

Apart from efficiency (that an optimizing compiler could at least partially re-gain), the matter is that of ease of coding - legibility and such. An additional '?' yields one more level of nesting and a whole bunch of hairy "dangling else" dangers. I mean: skipping the rest of the current iteration can't be done without more nesting since we have no GOTO (and rightly so, IMHO).