"Andreas Huber" <ahd6974-spamgroupstrap@yahoo.com> writes:
I did consider that and tried to explain why I failed. I'm afraid that I haven't been very successful in convincing people that the main obstacles aren't easy to overcome.
I think some of us are unsympathetic to the "it's hard" argument ;-) Maybe that's unfair, but it's the way it is.
It seems to me that if "orthogonal states" is the only feature in conflict with getting the highest dispatching performance, it ought to be possible to design a library whose performance only degrades if you use that feature.
I suppose you are inferring that from what I said in http://tinyurl.com/7ybeq? I see that this can easily be misunderstood. Fact is that the current interface *theoretically* allows for constant time dispatch, as long as orthogonal states are not used. If they are used you get O(n) dispatch where n is the number of currently active orthogonal regions.
That seems close to optimal, considering the alternatives.
However, there are a few practical problems for which I'll probably need help to overcome them.
But this library seems to have a design that's fundamentally incompatible with an approach like that. To get there, both the interface and the implementation would have to be redesigned IIUC. So that sums up why I think evolving toward support for lightweight FSMs is not likely.
See above, a few optimizations are theoretically possible but it is clear that the proposed FSM library will probably never earn itself the predicate lightweight.
I don't care if the library is lightweight (well I do a little). I'm talking about generating lightweight FSMs. But I suspect that's what you meant anyway. That would confirm my impression. -- Dave Abrahams Boost Consulting www.boost-consulting.com