From: Andreas Huber (ah2003_at_[hidden])
Date: 2004-09-03 15:07:24
Thomas Xkey wrote:
> This library seems & acts more like a "simulator" than an
> "efficient finite state machine".
Please define "simulator" and "efficient finite state machine".
> There is a very high level functionality tied into
> (possibly) a bare-bones base... not properly tiered or
> layered approach.
I believe the non-layered approach is a more or less obvious result of
the requirements defined in the rationale. If you agree with this
statement then please say exactly which requirements you have a problem
with. If you don't agree I'd be happy to hear your proposal how to make
boost::fsm more layered and how this layering introduces advantages
compared to the current design.
> It doesn't seem to scale well even according to the
> (most fsms a computer scientist would deal with encompass
> 100s to 1000s of states with
> as many different transitions possible)
Please say where in the docs you think I say that it doesn't scale well.
> I would strongly urge something more efficient and bare
> bones along the lines of
Unless I'm mistaken, this is a dynamically configurable fsm. For the
reasons explained in the rationale boost::fsm is a static fsm. I don't
think these two FSM variants can be compared in a meaningful way.
> take on the mantle of an "fsm" library in boost upon which
> coarse-grained objects can be simulated from
You seem to imply that boost::fsm is going to be *the* boost state
machine libraray forever (given that it is accepted). I don't think so.
boost::fsm does not offer top-notch performance and never will (I don't
think it is particularily slow either). boost::fsm is more geared
towards projects that need to quickly implement large and complex FSMs
drawing on all UML features. I acknowledge that boost::fsm *can* be the
wrong choice for some projects and I'm therefore not at all surprised if
another static fsm library with a different focus (e.g. along the lines
of the MPL FSM) will make it into boost in the not too distant future.
I strongly believe that a single best FSM implementation does not exist.
The problem domain is just too complex.
> would prefer this 'currently proposed' fsm to take on its
> true stance perhaps attaching the nomenclature
> of "hlfsm" --> "high level fsm".
I don't like hlfsm, but am otherwise open to suggestions for a better
name (I agree that boost::fsm isn't the best possible name).
> Due to its greater
> abstractions, fluffy aggregations
What do you mean with "fluffy aggregations"?
> and bulk in nature
> it isnt "efficient".
> If a library isnt efficient for its purpose or intended
> purposes then it will be under-utilized.
What do you think is the intended purpose of this library?
> I could never use this one
> as it is evolving away from an efficient
> fsm into more of a large coarse simulator. [now if i had
> need of that it would be great]
What do you use FSMs for?
> Can we adjust this library conceptually into a cleaner
> bare-bones fsm at one layer
As I said earlier: I'll happily consider your proposal on how to do so.
> and then interject the higher level simulation aspects
> along with the ability to
> automatically produce code etc.
No, this will not happen. One of the goals of boost::fsm was to get rid
of the code generation step. I strongly believe that code generation in
the FSM domain typically introduces more problems than it solves. Quite
a few people argue otherwise and if this means that my library is not
accepted then I will take it elsewhere.
> [Canned automatically generated code is usually not so hot.
For good reasons.
> In fact it rather bites. Any decent programmer can still
> out-optimize todays compilers based on
> intimate knowledge of their code & algorithms even on
> todays complex processors.
> Given that compilers have thousands of man-years of code &
> know-how how does one expect this fsm library
> to generate decent code or is it intended for someone who
> cannot program?]
Please define what you mean with "decent code". Again, a library that is
"decent" in one situation might be bad choice in another. Usability was
and always will be the topmost priority for boost::fsm. Yes, this means
that the library will never offer top-notch dispatch speed or ultra-low
memory footprint. Many projects using FSMs can easily trade some of
theoretically possible performance for more important things like faster
development. At least a few people seem to agree (TMK, there currently
are 3 real-world projects using boost::fsm with at least some success).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk