This is an unfortunate quirk popularized with ANSI C: calls to a function and calls to a function
through a pointer (or any level of pointer indirection) can use the same syntax. There's a
corresponding quirk applying to arrays. It further undermines the flawed "declaration looks like use"
philosophy.
Programming Challenge
Write an FSM Program
Implement the C declaration analyzer from Chapter 3 as a finite state machine.
- Review the "decoder ring" diagram, Figure 3-3 on page 76. This is a simple
state machine diagram! Program it this way, perhaps by modifying the cdecl
program you wrote back in Chapter 3. (You did write it, didn't you?) - First, write the code to control progress from state to state. Make each action
routine simply print out the fact that it has been invoked. Debug this fully. - Add the code to process and decode the input declaration.
The decoder ring is a simple state machine; most of the state transitions are in serial order
regardless of the input. This means that you don't have to create a table of transitions
matching state/input to get the next state. You can have a simple variable (of type pointer-
to-function). In each state, one of the things you will do is assign the next state. In the main
loop, the program will call the function pointed at, and so on until the end function or an
error state is reached.
How does the FSM-based program compare with the non-FSM version in terms of ease of
coding and debugging? In terms of ease of adding a different action, or modifying the order
in which actions occur?
If you want to get fancier, you can have the state function return a pointer to a generic successor
function, which you cast to the appropriate type. Then you don't need a global variable. If you want to
get less fancy, you can use a switch statement as a poor man's state machine, by assigning to the
control variable and putting the switch inside a loop. One final point on FSMs. If your state functions
seem to need a variety of arguments, consider using an argument count and an array of pointers to
strings, just as the main routine does. The familiar int argc, char *argv[] mechanism is very
general and can be borrowed with equal success for functions that you define.
Software Is Harder than Hardware!Did you ever notice that software and hardware are named the wrong way round—software is easier
to change, but harder in all other respects? Because software is so difficult to develop and get right, as
programmers we need to find ways to make it as easy as possible. One way to do that (and it applies to