State machines and undedefined symbols
Hi,
I've inherited some code that currently compiles and runs under Linux (gcc 4.2.1) and am looking to switch to Windows using the vs 2003.
Unfortunately the code fails to compile with undefined symbols. An example of the code is as follows:
#include
Hi Simon
I've inherited some code that currently compiles and runs under Linux (gcc 4.2.1) and am looking to switch to Windows using the vs 2003. Unfortunately the code fails to compile with undefined symbols. An example of the code is as follows: #include
#include #include #include #include <iostream> namespace sc = boost::statechart; struct EvStartStop : sc::event< EvStartStop > {}; struct EvReset : sc::event< EvReset > {}; struct Active; struct Stopped; struct Running; struct StopWatch : sc::state_machine< StopWatch, Active > {}; struct Active : sc::simple_state< Active, StopWatch, Stopped > { typedef sc::transition< EvReset, Active > reactions; }; struct Stopped : sc::simple_state< Stopped, Active > { typedef sc::transition< EvStartStop, Running > reactions; }; int main() { return 0; } I'm aware that the code is incomplete as Running is only forward declared. It is provided this way since the real model under Linux is broken up across multiple headers rather than all being in one header.
Ok, I guess this means that the whole machine is defined in one translation unit? If so, I don't see why you couldn't modify the include order, so that it compiles with VS2003 also?
Under Linux the above code compiles without an issue
Add the following to main() and it will no longer compile: StopWatch stopWatch; stopWatch.initiate(); This forces the instantiation of all code, including the transition to Running. So, gcc now should also complain about the missing definition for Running.
but vs 2003 complains about Running being undefined.
So does VS2008. Frankly, I'm not sure whether GCC is too lazy or VS too eager. But it shouldn't matter, if the whole machine is in one TU, you should be able to fix this by shuffling around includes (unless I'm missing something). HTH, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
participants (3)
-
Andreas Huber
-
Igor R
-
s_a_white@email.com