[boost] Re: Preliminary submission: Finite State Machine framework

From: Andreas Huber (ah2003_at_[hidden])
Date: 2003-06-03 14:27:47

Bohdan wrote:

> I'll port to borland, but i'm not exprert in gcc build system.
> For gcc better ask somebody else.

Thanks, I will get back to you as soon as I think the code is ready for
porting.

[snip]
>> Hmmm, I never liked it that much myself but I was forced to design
>> it this way due to some constraints of an earlier design. Now that
>> you mention it, I think it should be possible to specify the inner
>> initial state with the initiate() function, which could be called as
>> follows:
>>
>> Pump.hpp:
>>
>> class Pump : public fsm::state_machine< Pump >
>> {
>>   public:
>>     void Start();
>> };
>>
>> Pump.cpp:
>>
>> struct Idle : public fsm::simple_state< Idle, Pump >
>>
>> void Pump::Start()
>> {
>>   initiate< Idle >(); // ***** here *****
>> }
>>
>> Did you have something like this in mind?
>
> Definitely!

After posting I realized that the current interface already allows you to
hide states. E.g. you often want to ensure that a machine is initiated
during construction:

*StopWatch.hpp*:

struct Active; // the only visible forward
struct StopWatch : fsm::state_machine< StopWatch, Active >
{
  StopWatch();
};

*StopWatch.cpp*:

struct Stopped;
struct Active : fsm::simple_state< Active, StopWatch,
  fsm::transition< EvReset, Active >, Stopped > {};
struct Running : fsm::simple_state< Running, Active,
  fsm::transition< EvStartStop, Stopped > > {};
struct Stopped : fsm::simple_state< Stopped, Active,
  fsm::transition< EvStartStop, Running > > {};

StopWatch::StopWatch()
{
  initiate();
}

The trick is to place the initiate(); call in a location where all states
are known.

So, clients see only one forward declaration of the initial state while all
the other states are hidden in the .cpp file. However, this approach still
exposes the whole state_machine interface to the clients (StopWatch *must*
derive publicly from state_machine), which is often not what you want. In
real-world code you'd probably more often have the state_machine subclass as
a data member, maybe even more hidden with a pimpl.

I therefore think that it is not necessary to change the current interface
for information hiding purposes. Granted, it's not perfect, but the
alternative I've outlined in my previous post isn't either, as Reece has
pointed out. I might support both interfaces if there are other use cases
that don't work with the current interface.

Regards,

Andreas