From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-03-13 08:10:34
> 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.