|
|
|
|
|
|
|
{
cout << *************** << endl;
cout << *************** << endll;
}
//******************************************************************
void Print4Lines() // Function heading
// This function prints four lines of asterisks
{
cout << *************** << endl;
cout << *************** << endl;
cout << *************** << endl;
cout << *************** << endl;
} |
|
|
|
|
|
|
|
|
C++ function definitions can appear in any order. We could have chosen to place the main function last instead of first, but C++ programmers typically put main first and any supporting functions after it. |
|
|
|
|
|
|
|
|
In the Welcome program, the two statements just before the main function are called function prototypes. These declarations are necessary because of the C++ rule requiring you to declare an identifier before you can use it. Our main function uses the identifiers Print2Lines and Print4Lines, but the definitions of those functions don't appear until later. We must supply the function prototypes to inform the compiler in advance that Print2Lines and Print4Lines are the names of functions, that they do not return function values, and that they have no parameters. We say more about function prototypes later in the chapter. |
|
|
|
|
|
|
|
|
Because the Welcome program is so simple to begin with, it may seem more complicated with its modules written as functions. However, it is clear that it much more closely resembles our top-down design. This is especially true of the main function. If you handed this code to someone, the person could look at the main function (which, as we said, usually appears first) and tell you immediately what the program doesit prints two lines of something, prints Welcome Home!, and prints four lines of something. If you asked the person to be more specific, he or she could then look up the details in the other function definitions. The person is able to begin with a top-level view of the program and then study the lower-level modules as necessary, without having to read the entire program or look at a module structure chart. As our programs grow to include many modules nested several levels deep, the ability to read a program in the same manner as a topdown design greatly aids in the development and debugging process. |
|
|
|
|
|