Re: [Boost-users] Fw: State machine framework with dynamic configurability [repost]

From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-07-20 00:06:14

Dave wrote:
>>   PreIdle( my_context ctx ) : my_base( ctx ), EntryExitDisplayer(
>>   "PreIdle" ) {
>>     // Posting is now also possible with stack-allocated events
>>     post_event( EvPreIdleStart() );
>>   }
>
> Is this in the latest version of boost::statechart? My compiler seems
> to disagree with this statement:
[error snipped]

It should be possible with the version that I have released June 19th, 
which can be found here:

http://boost-sandbox.sf.net/Statechart.zip

>>  sc::result react( const EvPreIdleStart & evt )
>> {
>>   // Instead of mentioning the state machine directly with context<
>>   .. >, // the following is often more convenient
>>   return outermost_context().react( *this, evt );
>> }
>
> I agree, but my impression is that the react function could be
> implemented in any "outer context" which may not be the outmost one,
> right?

Hmmm, this never occurred to me. It would mean that you need to have 
something like the following

struct RunningBase : sc::simple_state< RunningBase, ... >
{
  virtual sc::result react( const EvX & ) { ... }
};

struct MyRunning : RunningBase
{
  virtual sc::result react( const EvX & ) { ... }
};

and then inside some inner state of RunningBase:

struct Inner : sc::simple_state< Inner, RunningBase >
{
  typedef sc::custom_reaction< EvX > reactions;

  sc::result react( const EvX & evt )
  {
    // depending on the requirements for the transition
    // (is it ok to exit and maybe reenter RunningBase),
    // we'd maybe also need to pass *this to react
    context< RunningBase >().react( evt );
  }
};

I've never tried but I don't see anything that would keep you from doing 
this. I can't currently think of a good example where this technique 
would make sense, please let me know if you find one!

[snip]
>> I haven't thought much about the implementation of StateFactory, but
>> it seems this should allow you to register arbitrary transitions
>> depending on the current state and the actual derived FSM class, and
>> give you the freedom you want?
>
> Sounds plausible to me, I should spend some free time thinking about
> how to implement this.

AFAICT, you'd be the first one to do something like this. I'd be 
interested to hear with what approach you settled in the end.

[snip code organization]
> I think the file names are pretty self-explanatory. The main program
> in core directory defines and uses the PumpBase FSM, and I want to
> implement a DLL (in the dll) directory and define MyPump to customize
> the PumpBase FSM. The main program would use dlopen/dlsym to load the
> DLL and get the factory that'll create MyPump. The include directory
> contains the header files shared by the main program and the dll.
> Everything compiles file, but when I run the program I get a runtime
> error from dlopen:
>
> Error loading MyPump.so
> MyPump.so: undefined symbol:
> _ZTIN5boost10statechart12simple_stateI7PreIdle8PumpBaseNS_3mpl4listIN4mpl_
> \
> 2naES7_S7_S7_S7_S7_S7_S7_S7_S7_S7_S7_S7_S7_S7_S7_S7_S7_S7_S7_EELNS0_
> \ 12history_modeE0EEE

Hmm, from the mangled name it looks like the *base* class of PreIdle 
cannot be found for some reason. I assume that PreIdle is declared and 
implemented in PumpBase.hpp, that is, everything is fully inlined? If 
so, I don't currently see why this happens. Unfortunately I'm not 
familiar with the details of .so file loading but I assume it should be 
roughly similar to Windows dlls. I guess it's probably easiest if you 
send me the full source by private email and I'll try to reproduce the 
problem with my compiler. BTW, are you using gcc?

Regards,

-- 
Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header.