From: Andreas Huber (ah2003_at_[hidden])
Date: 2004-05-26 08:16:18
Kwee Heong Tan <tan.k.h <at> juno.com> writes:
> I would like to get some clarification, so please correct me if I'm wrong.
> The first feature listed in the boost::fsm documentation is
> "straightforward transformation from UML state chart to executable C++
> Since straightforward is in the eye of the beholder, I think the following
> would convey more information :
> "Direct mapping of UML state elements to boost::fsm elements for simple
> but manual transformation from UML state chart to executable C++ code."
Agreed, that is probably a better description. I'll change that sentence.
> I am confused why having no code generator is considered a feature.
Code generation is useful, especially when both of the following conditions
- Humans don't need to read and/or modify the generated code.
- There is no library that allows you solve the problem with similar ease as
the code generator approach.
If, for a given problem, both of the above conditions do not hold then I
believe you're almost always better off with a library. We could now engage in
a discussion about the pros and cons, but I believe this is rather off-topic
for the boost list (recently there was a discussion about code generation on
c.l.cpp.m and I have expressed my opinion there).
The most important argument is that with boost::fsm you have a choice:
- You can easily manually implement FSMs
- You can write a code generator that generates boost::fsm client code
For FSM frameworks that are geared towards a generator front-end you almost
never have that choice as the generated code is much harder to read and
understand (tiny bits of user code are embedded in large chuncks of generated
> would seem the reverse is a feature, because a code generator would
> save coding time and eliminate human translation errors.
Sorry, but that sounds like the usual marketing stuff you hear from companies
selling code generators. I did work with FSM code generators and initially I
thought that they are a good idea. However, with time and experience I got
more and more convinced that in the long run they typically introduce more
complexity than they purport to remove, especially if there is a library that
allows you to very directly and easily convert UML to code.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk