From: David Abrahams (dave_at_[hidden])
Date: 2005-03-13 08:17:55
"Andreas Huber" <ahd6974-spamgroupstrap_at_[hidden]> 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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk