Boost logo

Boost :

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

> 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?


Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header. 

Boost list run by bdawes at, gregod at, cpdaniel at, john at