Last week I published my final installment of the finite state machine series of blog posts on Embedded Related. Here is a recap of the four posts –
- There’s a state in this machine! A motivation for state machines is presented to the reader. Starting from a simple C implementation of the concept, the snippet is analyzed and refined multiple times to address its shortcomings.
- Simple C++ State Machine Engine. The final snippet of the first post still mixed application logic and state machine engine. In this post, the state machine engine is decoupled from the application, and by successive refinements a simple C++ state machine engine is proposed.
- Unuglify C++ FSM with DSL. The engine resulting from the second post, although clear, required some boilerplate code, boring to write and potentially bug-prone if copied and pasted all around. In this third post, I propose a DSL implemented with the C++ pre-processor to make the FSM code more concise and clearer.
- FSM – Let ’em talk. In this post I try to scratch the surface of the problems you will face and the design decisions you are called to make when dealing with a concurrent system. Although these are not FSM-specific, you are likely to employ one or more FSMs to cope with concurrency.
The FSM topic is large and difficult to capture in just a few posts, I was overly optimistic that I could have tackled the subject with a couple of posts, but I soon realized that even three were not enough. If you want to go into details, there is much more to tell, but I think I addressed the most critical issues about how to write and use a state machine.
By looking at the viewing stats I see the subject has been of interest to many. And this makes me happy since FSM is a very popular subject, taught in schools and universities, a subject on which I could hardly say something new.
On the other hand, I am a bit surprised that the other post I wrote – on assertion checking at compile time – didn’t receive so much attention. I expected that showing how to convert potentially show-stopper run-time assertions, to compile-time checks would have drawn a bit more attention. Also, I showed how to define a compile-time-correct non-null pointer type which I was very proud of. I am unsure whether the title, mentioning assertions, is unappealing, or the topic is uninteresting to C++ programmers (we love risky life, we love rogue null pointers in our code).