4

In implementing a state machine using Boost.Statechart, I came across a problem arising from attempting to access the outer context of a simple_state from its constructor. A comment in simple_state.hpp tells me:

    // This assert fails when an attempt is made to access an outer 
    // context from a constructor of a state that is *not* a subtype of
    // state<>. To correct this, derive from state<> instead of
    // simple_state<>.

Apart from apparently being able to access the outer context from its constructor, what differences or implications are there in using state<> instead of simple_state<> as the base class for my states?

drfrogsplat
  • 2,577
  • 3
  • 19
  • 28

1 Answers1

5

There are a number of other things that you can do from a state<> derived constructor that you cannot do from a simple_state<> derived constructor. There are a list in the documentation for the state class. I found posting events to be the big benefit of deriving from state<>.

It's been a while since I used it, but I don't remember there being any implications, other than you having to implement the forwarding constructor for each class derived from state (stated in docs), as state<> is derived from simple_state<>.

tinman
  • 6,348
  • 1
  • 30
  • 43
  • 1
    Thanks! just found it in the docs here: http://www.boost.org/doc/libs/1_46_1/libs/statechart/doc/reference.html#ClassTemplatestate, which states: "Direct and indirect subtypes of state<> must provide a constructor with the same signature as the state<> constructor, forwarding the context parameter." – drfrogsplat Jul 01 '11 at 04:00