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:

>> 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!

>> 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
> 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?


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, kalb at, bjorn.karlsson at, gregod at, wekempf at