Boost logo

Boost Users :

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. 

Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net