Thinking Global...

In this model the data (the variables) are made "global": global variables are declared before, and outside of, the first function definition in the source file. Global variables are visible and accessible to all functions. Thus, if one function wants to call another sub-function and have that sub-function carry out some operation on some particular data values, the calling function can first store the data values in some global variables, then call the sub-function; the sub-function can then access the variables and do the processing; if some "result" is generated, it can be made available to the calling function by storing it in another global variable.

Have a look at the file TRI-GLBL.C. This is a somewhat contrived example program, showing functional decomposition and the use of global variables. Examine the program and try to understand how it is supposed to work. Note that, given my rule of thumb of defining functions in reverse order, the sensible way to read a C source file is to start at the bottom and work backwards. That is, you should generally start by looking at the main() function. Try to get some understanding of it in isolation first. Then start looking at the functions which main() calls to get some extra detail on what is going on. Then, if necessary (it does not arise in this particular program) you can have a look at the functions which are called by that function in turn, and so on, effectively working your way back toward the top of the source file.

Play with TRI-GLBL.C. In particular, experiment with single stepping through it. Try to predict where execution is going to go next at each stage, and then check whether you are right. Use the Watch window to monitor the variables. Again, try to predict when changes are going to happen, and see if you get it right. Notice how execution transfers to a sub-function, then returns to the calling site. Notice how the global variables are allowing information to be accessed or shared between different functions. Try varying the program somewhat: e.g. to calculate the area of a rectangle, or square; or to repeat the calculation for a number of times; or to initially print out some kind of "welcome" message before doing any calculations; or extend the program to be able to calculate areas of several different shapes - so that it first has to ask for the kind of shape to be identified (e.g. saying "Enter 1 for triangle, 2 for square:" or something like that), and then read the appropriate data for the particular shape, and do the appropriate calculation.

Note that in TRI_GLBL.C none of the (sub-)functions actually have a return statement as such. A feature of C functions is that if execution reaches the end of the function definition - i.e. the brace which closes the definition - then the function will be terminated anyway and control will automatically return to the calling site, just as if a return statement had been executed. Thus, if you have a simple return statement as the very last statement in a function definition it can actually be omitted - and usually is. By a "simple" return statement I mean one without an operand - unlike the return statement in the main() function which has an operand (namely 0). The significance of this operand will be explained shortly: for now the point to note is that, if a return statement does have an operand, then, even if it is the last statement of a function definition, this return statement cannot be omitted.