If I use break; in a state in the child switch how do I know it won't break the state in the parent switch?

It's safe to assume that never happens. “break” only works on the innermost for-loop, while-loop, or switch statement.

Calin said:
how do I know it won't break the state in the parent switch?

As Alberth said, but besides:
Place a breakpoint to the inner switch, run in debug mode and see what happens.

You know because the language requires it. It exists the innermost one (for, while, or switch) and continues to the next statement after it. You can nest it as far as you want, it still only exits the innermost.

The debugger is useful to see it in action, but it is the language standard itself that guarantees it.

In other words if you want to break the main switch state from within an inner switch state you would have to use a separate variable (a bool) that can trigger a main switch state break. Thanks.

JoeJ said:
Place a breakpoint to the inner switch, run in debug mode and see what happens.

I'm using breakpoints at times but I find using breakpoints to be a technology abuse. I'm much more comfortable with log files.

(Visual Studio environment is a hot potato, you can easily break stuff by deleting or adding stuff my accident, you can't break things in a log file ) )

Calin said:
but I find using breakpoints to be a technology abuse.

Well, people have thier convictions… but this is just nonsense.
They have even built in debugging support into CPU hardware, so that we can do better development.
Using the features of the HW is our job, not abusing something.

Calin said:
Visual Studio environment is a hot potato, you can easily break stuff by deleting or adding stuff my accident, you can't break things in a log file

I never broke anything while debugging. You don't edit code while debugging, you only observe it's execution.

I should start to use the debugger more often, besides the log file. Use both.

Calin said:

In other words if you want to break the main switch state from within an inner switch state you would have to use a separate variable (a bool) that can trigger a main switch state break. Thanks.

It depends on details. In general that situation feels like a design flaw, although as you're still learning there are great things to learn.

Needing to know inner details of how a switch ended likely means the details of the inner switch would be better handled as a function that returns that detail, rather than as an inner-control-block manipulating an outer-control-block.

Switch statements are great and have a lot of good uses, but they're also often a code smell that something is hard-coded. In larger systems hard-coded values tend to be difficult to extend and grow, and generally should be made dynamic. Data-driven solutions, virtual functions, collections with function pointers in the form of lambdas, callbacks, delegates, or similar all tend to be good alternatives that aren't locked into hard-coded options.

For smaller solutions or something you know is fixed and will never need to handle additional scenarios, nested switch like you describe is fine. And obviously, for learning you end up writing all kinds of code that once you've learned it you'll never revisit the concept.

Calin said:
In other words if you want to break the main switch state from within an inner switch state you would have to use a separate variable (a bool) that can trigger a main switch state break.

Actually you can ‘break’ out of multiple nested scopes using the goto keyword.

(That's usually considered bad pactice, but every tool has its nail)

frob said:
In general that situation feels like a design flaw

Thanks. I've seen one switch statement hosted by another switch statement without the mediation of a function. It got me wondering how would that work.

JoeJ said:
using the goto keyword

I remember someone saying on codeproject.com that goto defeates the purpose of c++ ) Maybe the person was talking about a particular situation I don't know.