CASE Statements Not Falling Through

[clevername27]

@d-healey (Yes, it must be INIT for the top case to file.) Good question; the issue manifests if I simply comment out the two functions.

It seems like, regardless of any other code, if this executes…

Console print("---------------------INIT" );

… then…

Console print("---------------------READY (Fall-throough)");

…should excute, yes?

Possible culprits -

• A compiler optimisation incorrectly assuming the CASE wouldn't fall through. (I have it turned off, as far as I know.) I've had this happen in the past.

• A callback, or broadcaster is stealing execution, and not returning it or (or other unexpected programme flow). An example (if memory serves) is the "loading" interrupt that didn't get called at the right time (consistently), creating the need for the recent broadcaster replacement for this functionality.

Thank you again.

[d.healey]

@clevername27 I'm not sure what you are expecting to happen, if moduleState is "init" then it will go to the first case and exit. Are you expecting it to go into the "ready" case?

[clevername27]

@d-healey Yes. Does HiseScript not support that?

[Lindon]

@d-healey said in CASE Statements Not Falling Through:

@clevername27 I'm not sure what you are expecting to happen, if moduleState is "init" then it will go to the first case and exit....

As @clevername27 suggests, without the "break;" statement switch statements should "fall thru" not exit...

[Christoph Hart]

@Lindon yeah I guess I never bothered about this functionality.

The problem is that if I implement that now there might be scripts that left out the break statement and this would change their behaviour, so I guess we‘re stuck with the current behaviour.

I can add a warning if you forget to add a break statement though then it at least won‘t be confusing for people that expect it to work like the standard switch statement.

[d.healey]

@Christoph-Hart said in CASE Statements Not Falling Through:

The problem is that if I implement that now there might be scripts that left out the break statement and this would change their behaviour, so I guess we‘re stuck with the current behaviour.

Preprocessor definition to enable it.

Interestingly the default case will still trigger

const t = 5;

switch(t)
{
    case 5:
	Console.print("Case is 5");
    case 10:
	Console.print("Case is 10");
    default:
	Console.print("Case is default");
}

[Lindon]

@Christoph-Hart LOL - I've been adding "break" statements like a demon for years in HISE - are you now telling me I need not have bothered??? Theres a million key strokes I wont get back, :beaming_face_with_smiling_eyes:

[Christoph Hart]

Preprocessor definition to enable it.

Nah, I don‘t think this is necessary. It will be confusing and error prone if you forget to set this flag plus it will be something that I‘ll implement and deactivate right after it and we know from experience how long these kind of things stay unbroken :)

[clevername27]

@d-healey Thank you - that helps a lot. Cheers.

[clevername27]

@Christoph-Hart Respectfully, if Case statements always break, that's a language design choice; if the default case always executes, that's a significant issue. I agree with @d-healey that it needs to be a preprocessor — even if that's just to enable the default case. I'd also pls suggest adding the current case implementation to the documentation (if not already there).

[clevername27]

@Lindon If it's any consolation, I need to go back and pour through thousands of lines of code.

[d.healey]

@clevername27 said in CASE Statements Not Falling Through:

if the default case always executes,

It always falls through, so if you don't put a break statement in the other cases then it will execute - but it is the "default" case after all so then that's probably fine.

[clevername27]

@d-healey Yes, but ALL of the cases should execute — having only the last execute is unintuitive, no?

[d.healey]

@clevername27 said in CASE Statements Not Falling Through:

having only the last execute is unintuitive, no?

Yes, always use breaks and you will avoid the issue, and Christoph can add that warning he mentioned.