I have extensive recent experience with applying FSM based logic to performance important parts of several utilities. But unfortunately I did not have a time and resources to invest into review for this submission. I only read tutorial. I must say it left me .. well .. open-mouthed: Why would anyone use solution like this?
I guess because for some people performance is a lot less important than features and expressiveness. I strongly believe that there is a sufficiently large class of applications where this library will not cause any noticeable overhead, which at least some users have confirmed.
1. All states are .. well .. stateless. no way to save anything into state - it gets destroyed every time
Hierarchical states solve this problem.
2. I have to spend time every time on new,
Did you notice that you can overload operator new and delete for all states?
constructor, destructor for each state
For good reasons (to satisfy the scalability requirements).
3. From what I see there is no way it could have constant dispatch time (just guess - no real analysis - but I would be really surprised if it's not true)
The interface theoretically allows for O(n) dispatch, where n is the number of orthogonal regions. So, if you don't use orthogonal regions you get O(1) dispatch. This is not yet implemented though and there are a few practical problems that need to be cleared first.
4. Interface limitations seems unreasonable: why would deferred event needs to be supplied as intrusive_ptr?
Have you read the rationale for that? Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.