Re: [Boost-users] State machines and undedefined symbols

Subject: Re: [Boost-users] State machines and undedefined symbols
From: Andreas Huber (ahd6974-spamboostorgtrap_at_[hidden])
Date: 2010-03-11 16:34:29

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 <boost/statechart/event.hpp>
> #include <boost/statechart/state_machine.hpp>
> #include <boost/statechart/simple_state.hpp>
> #include <boost/statechart/transition.hpp>
> #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.