From: David Abrahams (dave_at_[hidden])
Date: 2005-03-07 08:37:14
Andreas Huber <ahd6974-spamgroupstrap_at_[hidden]> writes:
> David Abrahams <dave <at> boost-consulting.com> writes:
>> "Andreas Huber" <ahd6974-spamgroupstrap <at> yahoo.com> writes:
>> > I don't think so. Even with Aleksey's approach, with an FSM becoming
>> > sufficiently large at some stage the compiler will give up because it
>> > reached its template nesting depth limit or compilation becomes
>> > infeasible because it takes too long (usually because the compiler eats
>> > up so much memory that there's a lot of swapping).
>> That could happen in any program that uses templates. Or uses a
>> compiler, for that matter. I believe this to be FUD, and false for
>> practical sizes of FSMs.
> The BitMachine example shows that at least one current compiler (MSVC7.1)
> fails to compile a flat state machine having between 32 and 64 states (at the
> time when the library still worked on MSVC6.5, it failed with < 16 states).
> Exactly where it fails I didn't test, moreover it is a rather arificial FSM
> that noone would construct in practice. Unfortunately I don't have real-world
> experience with machines that large but I do have feedback that such large
> FSMs exist in practice (40 states). Moreover, I expect the problem to become
> worse with the use of hierarchical/orthogonal states. For me this is enough
> evidence that I cannot just ignore the issue.
I'm not saying that Aleksey's library can handle all practical state
machines. I'm saying that it's possible to build a
statically-dispatched FSM library that handles all practical state
-- 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