[boost] Re: FSM Review

From: Alexander Nasonov (alnsn_at_[hidden])
Date: 2005-03-12 18:48:29

Jeff Garland wrote:
> Perhaps, but I suspect there would be different tradeoffs with an alternative
> design.  The other side is that if more time had been spent, it might have
> been like hash_map -- it would have just been absent.  Where would C++ be if
> std::string wasn't part of the lib? Hard to imagine. In fact, 98% of the time
> when I'm writing a program I could care less about the traits template
> parameter and the other failings of std::string.  BTW, I don't think I've
> seen a proposal that identifies and eliminates all the std::string issues -- I
> suspect that's because it's very difficult to balance the entire design space
> for strings in a single interface.

Unlike std::string, FSMs aren't used in 99% of C++ projects, especially
big ones. It's a special market and only those who work there might have
problems similar to lack of std::string. They know it better.

However, FSMs are quite often used to describe class behavior but
most of the time those classes are implemented without any fsm library.
People just look at the diagram, then define a couple of bool members
or 'int m_state;' and then they check restrictions imposed by fsm in
every function drawn on the diagram (events are usually function calls).

Typical example of such class is POAManager (CORBA). It has active,
holding, discarding, inactive, start and end states and there are
create_POA, activate, discard_requests, hold_requests, deactivate and
destroy functions.

I'd be happy to see a library in boost that can elegantly solve
problems of such classes. Common problems are

1. Class invariants depend on state. This usually means that they lose
   simplicity and effectiveness.
2. Some class members are valid only in certain states. (Andreas has
   proved that state local storage is useful thing)
3. Because of 1 and 2, it's harder to maintan even basic exception
   safety.

Because classical approach to implement POAManager and the like
is not overly complex and because no special skills are needed,
new library should have several advantages (to give answers to problems
1-3, at least) and it should have very clear and easily understandable
model.
Tutorial of this library should describe how to solve typical problems
of classical approach.

If this approach is taken, fsm may become a second tool after
std::string :) (just kidding, there are a lot of more important tools)
-- 
Alexander Nasonov