I feel as if separating the state description/object/variables from the actual operations feels better--personally, I've coded a state machine for a CAD drawing program in Lisp, and it's missing a lot of the OOP and RAII concepts from C++, but I still managed to create a good state machine that was easier to debug by passing around a list of parameters that described the state of the state machine, coding in transitions inside the state functions.

I would say that it would be good to parametrize your state into a variable or external structure instead of derived classes--inheritance, dynamic behavior, and polymorphism can be quite hairy if you keep trying to do this. This way, you won't have to create new classes every time you need to expand or fix behavior, and you won't have to look through multiple classes or files when you have a behavior error--instead, I might code the different states as function objects or closures and then go on from there.

Perhaps what you could do is to call different functions based on the current state, and attach references to the resources you need to pass between states; perhaps you could even move from them as well.

I feel as if separating the state description/object/variables from the actual operations feels better--personally, I've coded a state machine for a CAD drawing program in an old, domain-specific form of Lisp that's missing a lot of the OOP and RAII concepts from C++, but I still managed to create a good state machine that was easier to debug by passing around a list of parameters that described the state of the state machine, coding in transitions inside the state functions.

I would say that it would be good to parametrize your state into a variable or external structure instead of derived classes--inheritance, dynamic behavior, and polymorphism can be quite hairy if you keep trying to do this. This way, you won't have to create new classes every time you need to expand or fix behavior, and you won't have to look through multiple classes or files when you have a behavior error--instead, I might code the different states as function objects or closures and then go on from there.

Perhaps what you could do is to call different functions based on the current state, and attach references to the resources you need to pass between states; perhaps you could even move from them as well.

I feel as if separating the state description/object/variables from the actual operations feels better--personally, I've coded a state machine for a CAD drawing program in Lisp, and it's missing a lot of the OOP and RAII concepts from C++, but I still managed to create a good state machine that was easier to debug.

I would say that it would be good to parametrize your state into a variable or external structure instead of derived classes--inheritance, dynamic behavior, and polymorphism can be quite hairy if you keep trying to do this. This way, you won't have to create new classes every time you need to expand or fix behavior, and you won't have to look through multiple classes or files when you have a behavior error--instead, I might code the different states as function objects or closures and then go on from there.

Perhaps what you could do is to call different functions based on the current state, and attach references to the resources you need to pass between states; perhaps you could even move from them as well.

I feel as if separating the state description/object/variables from the actual operations feels better--personally, I've coded a state machine for a CAD drawing program in Lisp, and it's missing a lot of the OOP and RAII concepts from C++, but I still managed to create a good state machine that was easier to debug by passing around a list of parameters that described the state of the state machine, coding in transitions inside the state functions.

I would say that it would be good to parametrize your state into a variable or external structure instead of derived classes--inheritance, dynamic behavior, and polymorphism can be quite hairy if you keep trying to do this. This way, you won't have to create new classes every time you need to expand or fix behavior, and you won't have to look through multiple classes or files when you have a behavior error--instead, I might code the different states as function objects or closures and then go on from there.

Perhaps what you could do is to call different functions based on the current state, and attach references to the resources you need to pass between states; perhaps you could even move from them as well.