FSM: why not store the states *in* the FSM?

[jaskij]

I'm writing my code while working through etl::fsm examples, and a question arose: why are the states stored outside the FSM? In other words, what are the possible downsides of making the states members of the FSM class?

In the context of the QueuedFSM.cpp example, this would mean that instead of having state1 and state2 variables in main(), they are part of the Fsm class.

What am I not seeing? What are the downsides? Is it compatibility with older C++ standards? Sheer object size? Something else?

[jwellbelove]

It is not mandatory to have the states defined outside of the derived FSM class, that's just the way that I originally wrote the examples. There is no reason why you can't define them as members.