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.