Larger structured state machine; implementation issue

[laktofil]

This may seem like an abstract question on behavioral inheritance. Anyway, I'm building a hierarchical state machine in C++ (with gcc for target platform Gentoo Linux). More precisely, I'm using this framework: Practical Statecharts in C/C++: Quantum Programming for Embedded Systems (hopefully, you don't have to know it to answer my question). Summary is that a state is represented as a function and state changes are handled by member-of-functions pointers. Very structured and efficient! The hard part is how the (somewhat abstract) behavioral inheritance is implemented through C++ polymorphism)

The base class, "the core", has all the important functions for dispatching the state machine and organizing the state changes. This class must be inherited by all other classes to make them executable as state machines (through the behavioral inheritance).

Let's make an simple illustration of a state machine.

[core]--+--[state 1]--+--[state 11]--+--[state 111]
                      |              +--[state 112]--+--[state 1121]
                      |              |               +--[state 1122]
                      |              +--[state 113]
                      | 
                      +--[state 12]--+--[state 121]
                      |              +--[state 122]--+--[state 1221]
                      |                              +--[state 1222]
                      |                              +--[state 1223]
                      |  
                      +--[state 13]--+--[state 131]
                                     +--[state 132]
 
 

As you see, it will get very messy to have all these states defined in one class, even in one file! My idea is to keep every "layer" (vertically paired states in illustration, e.g. state 1x, 11x, 12x and so on) in separate classes.
But, how do i define a such inheritance (the first level is simple, I have it working already)? All classed have to be in the same state machine, and inherit the "core" functionality directly or indirectly, but without actually creating a new instance of the core! Since there are a lot of branches, I cannot simply create the "highest" layer and let it recursively create all superstates down to the core as the usual way to go would say.
Should I maybe use:
* Friend classes?
* Inheriting without calling super's constructor?

Bonus feature: Substates like '1121' and '1221' (in the illustration) will be very similar in behavior, so it will be great if it's possible to make them descend from the same same (virtual) class and just define the differences for each branch. Will this be as easy as making pancakes thanks to multiple inheritance?

If you don't understand what I'm talking about this far, some reference to "advanced" class inheritance in C++ with examples would probably help me very much :)

Thank you for your time!

[JosAH]

Just a thought: can a state be a Composite (see the GoF book for a definition)
so that a state *is-a* state (trivial) and also *has* states? I don't know how the
entire machine changes its state but maybe such a Composite could do the job.

kind regards,

Jos

[Banfa]

Have you looked at the State Design Pattern, descibed here?

[laktofil]

Thanks for good answers guys!

@ JosAH
I've looked at some composite examples, and that is probably what I need to initialize all state classes. Unfortunately, I can't really for the moment think of any way this pattern can solve all my problems due to the predefined framework from the book.


@ Banfa
Yes, I had a look at some examples from bytes' library just after I posted. They're good, but doesn't quite solve my multi-state-per-class-problem, but I got some ideas to work on.

And I added GoF's Design Patterns to my wishlist. I'll solve this problem in some more or less elegant way after reading some more articles about chain-of-responsibility and template patterns.

Thanks
Stefan

[Banfa]

Yes, I had a look at some examples from bytes' library just after I posted. They're good, but doesn't quite solve my multi-state-per-class-problem, but I got some ideas to work on.

The thing to do would be 1 state per class not multiple states per class. Each class will then have very simplistic behaviour I think trying to have multiple states per class will result in complex class behaviour and will basically negate most of the advantage you would get from using classes.

Don't make the mistake of thinking your class hierarchy will inherit down your state tree. Classes and states are 2 separate things. What I normally do is have 1 abstract base class defining the interface to the states and then have each state as a sub-class of that base.

The example I linked to is using a state machine that deals with a synchronous operation, reading a file, but where I have implemented it the operation has been asynchronous dealing with events from 2 different sources (user interface and comms interface) so where the example has a DoProcess function I have implemented a number of different functions to handle different events with different attached data. The base class then holds default handlers for these events for states in which they should not occur (because there is a difference between should not and can not).