Hi Alexander,
Iain K. Hanson wrote:
I'd love to see a DSL ( Domain Specific Language ) for state charts that generated Alexsey style FSMs with states able to be defined in seperate compilation units. This would solve the scaleabilty problems.
If you're talking about this http://boost-consulting.com/boost/libs/mpl/example/fsm/player2.cpp then there is nothing to put in separate TUs because states are numbers. Probably, you mixed states up with transitions. This is more a problem of proposed Boost.FSM then yours. In my
I don't think so. Even with Aleksey's approach, with an FSM becoming sufficiently large at some stage the compiler will give up because it reached its template nesting depth limit or compilation becomes infeasible because it takes too long (usually because the compiler eats up so much memory that there's a lot of swapping).
opition, too many things are put in state definition and too much a user has to remember:
1 curiously recurring template pattern
Why is it a problem to remember that?
2 forward declaration of events
You mean states? That shouldn't be too hard either?
3 state context
This is inherent in the UML model, no?
4 transitions and other reactions
Ditto.
5 other advanced features (only for advanced user)
Ditto and you only have to remember what you actually use.
I think some of them should be defined somewhere else.
Where? Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.