>> I ended up implementing timeout support with a WM_TIMER handler in the
>> parent of the state machine class. ...
>
> Does the WM_TIMER handler really add the event to the queue of the

> state_machine subclass object? If so, then you might have introduced
> a race condition. WM_TIMER handlers are called in a dedicated thread,
> right?

From my understanding of the documentation of SetTimer and my use of it, 

everything should be working from the same thread (WM_TIMER messages are 
posted to the main thread's message queue, where they are processed while 
the thread is idle).  So, I don't think there's a race condition.


>> Also, like the Camera example, I implemented a
>> post_event in the
>> constructor/entry of some states, which also requires derivation
>> from state,
>
> Correct.

>
>> and awkward instancing of the event.
>
> I don't understand. You mean the special constructor you have to add
> to the state, right?

Well, that, but more importantly, the cast inside of the post_event.

Making calls to post_event from a constructor/enter seem like a fairly
typical use case.

>>  Would using methods (Entry/Exit)
>> instead of
>> the constructor/destructor ease some of these problems?

>
> This is a somewhat controversical topic. During formal review there
> were a few people who favored entry() and exit() functions over the
> current ctor/dtor design. 

Thanks for the explanation (removed for brevity), and the sample code!