A. What do you ( more experienced programmers than me :) think about that? Is it the "correct" way to design such a class? Are there performance issues ?
OK! I had a rough look at your design, and it doesn't really feel good to me for a general purpose FSM framework. That's too narrow to be usable in a widened context. Some points of critique:
- You're depending on Qt :( ; at least you should use C++ STL components for your implementation details.
- Your states should be (specialized) classes on their own, that implement the behavior directly. The FSM class itself, should be independent (especially not implement) from their behavior.
- You don't support more complex state diagrams, including sub-state (machines)/composite states, concurrent FSM pathes (fork, junctions), active states (repeated asynchronous do operations), ...
In general I'd recommend to follow the GoF State Pattern for FSM implementation. For very simple state diagrams a switch(event)
case <event>: changeState(newState)
might be enough. But to render events as method entries of the FSM, and delegate these to the current state class instance, makes the whole construct much more flexible. Think about optional parameters coming along with a particular event, and you'll need to extend your state machine design for these.
In general your approach to use a CRTP for your state machine is a good idea, but for what you demonstrated, simple dynamic polymorphism (using virtual member functions) would work well also.
About performance issues, don't think you will hit ones with your current environment, but that completely depends where and in which context you want to deploy.
I want to recommend you having a look at my State Machine Class Template framework STTCL, which provides various C++ template based aspects of UML 2.0 compliant state machines, following the already mentioned GoF State Pattern.