A proposal to add statemachine support to C++-like language

Question

Lately as part of my day job I've been learning IBM Rhapsody and using it to generate code in C++ from the UML.

Yesterday it struck me that it might be cool to think about adding state machine support to my C++ compiler, so I jotted a few notes here: http://ellcc.org/wiki/index.php/State%5Fmachines%5Fand%5FActive%5FClasses

My motivations for doing this are:

1. It seems like a cool idea.
2. The compiler could do much better semantic checking (with better error checking) than the current Rhapsody/normal C++ compiler.
3. There are many optimization possibilities available when the compiler itself understands the state machine structure.

I may try to extend my grammar to except something like the proposal to see how well it works.

What is your opinion of the proposal? Does it seem readable? Does it seem worthwhile?

---

Edit:

Thanks for the answers recommending specific libraries to do state machines, but that wasn't my question. I've implemented many state machines using both libraries and code that I've written.

I was really looking for ideas, criticism, etc. about the design of a state machine extension to a C++-like language, not whether this change would be appropriate for addition to standard C++. Think of it as a domain specific extension, where my my domain is real-time control applications.

I've started implementation of the extension in my compiler as described here: http://ellcc.org/wiki/index.php/State%5Fmachines%5Fand%5FActive%5FClasses

So far the concept hasn't had to change much going from proposal to implementation but there have been a few changes in details and I'm refining my understanding of the semantics of the problem.

Time will tell whether the whole concept has any value, however. ;-)

Answer 1

With a few exceptions, C++ has traditionally been extended using class libraries, not new keywords. State machines can easily be implemented using such libraries, so I don't think your proposal has much of a chance.

One problem I see in your proposal is the use of 'goto' to go to another state. What happens if I want to use goto in my own code within a state transition?

Answer 2

It's an interesting idea, but I think you'd actually have better luck creating your own domain-specific language for state machines than officially extending C++. C++ is designed as a very general-purpose programming language. I think Boost has proven that C++ is flexible enough that most features can be implemented nicely using libraries. It also evolves very slowly, to the extent that standard C++ still doesn't even have built-in threading support as of 2009, (it is planned in 0x). So it's unlikely the committee would consider this addition for some time.

Answer 3

Excellent work developing what you've done. Something like you've done probably is possible, but I'm doubtful it would ever get into the C++. Most changes that make it into the language itself are included only to allow people to write more useful and powerful libraries.

There's a library here that provides support for state machines. I haven't tried it, but it might interest you, and you may be able to combine your ideas with a library like this to allow other people to make use of it.

http://www.boost.org/doc/libs/1%5F34%5F1/libs/statechart/doc/index.html

Or, you could develop your own extension as you suggest, and it would at least be useful for you. Microsoft implement some extension keywords, so there is no reason why you couldn't create your own extended version of C++.

Keep the new ideas coming.

Answer 4

You should take a look at how another smart developer added State machine support to a C-like language: UnrealScript Language Reference. See the section named "States".

UnrealScript supports states at the language level. In UnrealScript, each actor in the world is always in one and only one state. Its state reflects the action it wants to perform. For example, moving brushes have several states like "StandOpenTimed" and "BumpOpenTimed". Pawns have several states such as "Dying", "Attacking", and "Wandering". In UnrealScript, you can write functions and code which exist in a particular state. These functions are only called when the actor is in that state

Answer 5

Your solution does not look like it has any advantages to a template- or preprocessor-macro-based solution.

I am also not sure, how you can provide better semantic checking. And I doubt that you can apply many useful code optimizations.

However, to allow better optimizations and semantic checking, you should also replace "goto" with a new keyword (e.g. __change__ newState), and disallow goto for state changes! Allow goto for local jumps as usual.

Then the compiler can extract a list of possible transitions.

Answer 6

Read your proposal, have the following comments:

1. There's actually no keyword to declare and define an actual state machine! Do you assume a single global state machine (and thus a single global state)? How does that relate to __active__ ?

2. The closest comparable construct in C++ is actually the enum. Why not extend it?

3. There seems to be some connection between defined events and states, but I fail to see how it's implemented.

4. Why are threads and timers needed at all? Some use cases of state machines may benefit from them, but a good proposal should keep these seperate. Most importantly this should allow the use of standard C++0x threads.

Personally, I would extend the enum syntax:

enum Foo {
  red, blue, green; /* Standard C++ so far - defines states. State list ends with a ; not a , */ 
  Foo() { *this = red; } // Reuse ctor syntax, instead of __initial__
  ~Foo() { } // reuse dtor syntax, instead of __onexit__

  void Bar() {/**/} // Defines an event, no return value. Doesn't need keyword __event__
};

It follows naturally that you can now declare your events in a header, and define them in a .cpp file. I don't even need to suggest the syntax here, any C++ programmer can guess that at this point. Add a bit of inheritance syntax for combined states:

enum DrawingObject : public Shape, public Color { /** } // allows (red && circle)

and you're pretty much at the point where your proposal is, without any new keywords, all by reusing an already familiar syntax.