Upon successful completion of this project, the student will be able to:
A. Be able to create and implement data structures,
B. Declare arrays within a C++ program,
C. Input data into an array of data structures (records),
D. Search arrays of data structures,
E. Sort data within an array of data structures
F. Output data from arrays to either a CRT or print (text) file.
A. Proficiency in the use of standard variables,
B. Able to use decision and looping control structures,
C. Understand the creation and use of user-defined functions including passing data,
D. Use of comment sequences as prescribed in the Style Manual.
In project 3 an input sequence was created such that data was entered into a standard variable sequence. As we have seen, several difficulties arrise using this technique: First we have to make sure all of the data is passed to each of the I/O modules and secondly we could only enter a single set of data. To resolve these issues we can combine the set of related data into a single package - the structure or class. Then we can create a collection of the structures or class into an array of structures or classes. In our studies we will focus on the structure data package.
The first issue then is to create a data structure which collects all of the related data variables into a single unit. This unit, in many ways, acts like a data type. We sometimes call the data structure a "user-defined data type". Relative to standard data types it is relatively complex (but NOT complicated!!). Once the data structure is created then it is just a matter of creating a collection (array) of these data packages.
Once the array is created the program can now access a whole series of data sets. It can sort the data, search for specific values, edit a given package in the array, or simply print out the set of data.
For example, in that operations have been relegated to "simple" variables, the creation of tabular output has not been practical. However, with the use of arrays, it becomes feasible to "store" collections of data in the array which allows output to a table or report.
Array operations are typically accomplished using iterative (looping) operations, most typically using the while() and its "cousin" the for(). The two looping structures can often be used interchangeably, however the rule-of-thumb is, if the limits of the loop are known and there is a single test, the use of the for() is recommended otherwise the while() function is recommended. Therefore "traversing" the entire array is usually accomplished using the for() loop. Figure 10 presents an algorithm useful for doing traverse operations. On the other hand, if it is expected that the entire array may not be traversed or if multiple relationships are to be tested, the while() function is typically used. Figure 11 shows the utilization of the while(). Both figures assume the appropriate variables have been initialized.
for (ctr=starting value, ctr <= limit, increment ctr)
Figure 10. Typical operation algorithm of a for().
while ((ctr < limit) and (check flag for completion))
if (operation has been completed)
set completion flag
Figure 11. Typical operation algorithm of a while().
Note that the while() often has two or more conditions that can terminate the sequence, both tested in the while argument. Within the body of the loop the if() is used to determine if the operation sequence has been completed by setting a flag variable. The for() not only tests the condition of the counter, it initialized the value of the counter, and increments the value of the counter within the for() statement. Note the for() typically has a single test.
In programming, one often sees the for() being used in sorts and the printing of tabular output; the while() being used in data searches and input. Similar uses will be applied later when using "linked list" algorithms.
Another technique programmers often use is the direction of output to alternate files or devices. C++ treats files and output ports in a similar manner. In C++ both are considered to be "devices". Figure 12 shows a code sample that directs values to a "FILE" device. Notice the value, the "file name" used to identify the device (file). In this case the device (or file) name is "printer_output.prn" ; the ".prn" identifies the type or purpose of the file. The reference object in the program is printer. The programmer can create a string variable to be used in place of a string constant creating flexibility in the use of the program sequence (that is another story). After the execution of the program, you can print the contents of the text file using a text editor such as "MS Word" or "OO Writer".
#include < iostream >
#include < fstream >
ofstream printer; // ofstream means out file stream
cout<<"Enter a word (Max 14 chars): ";
printer << "The values are: " << i <<" " << fval << " " << name;
Figure 12. Sample programming for opening an output device and redirecting output to that device.
The usefulness of the program can be enhanced by the program's ability to manipulate sets of data. The following are the tasks the program should be able to perform.
The operations listed above will probably require user prompts (sub-menus) called from the main menu.
The data to be used should be the same as that which is specified in projects 2 and 3.
Modify Project 3 such that all user input is made into the data members of a structure by way of string buffers. An array of structures should be created with a maximum of 25 elements or structures. New "wrapper functions" will be need that incorporate loops. These functions will call the basic input and output functions developed in project 3. New modules will be required for searching, sorting and printing the resulting tabular output. The single record display module created in project 3 should be used for the display of sthe search results. The coding should be commented as prescribed in the Style Manual (Brunjes and Shultz, 1993).
As with previous projects any new screens created for this project should be consistent with the general format created in Project 2. All user input should be checked for reasonableness. Anticipated or observed error sequences which are not within the scope of this project should also be documented. All calculations should be "desk checked" and noted on the output/screen. And as before, all calculations should be tested with a range of appropriate values.
As in project 3 the project will be submitted in two parts - the development/design documents and the listing/demonstration.
Screen design for each new screen - be sure the program name and page title are on each screen,
Program Hierarchy chart - must show all user-defined modules,
General pseudocode/flowcharting for each new module.
Print file creation,
Real-time demonstration of the program.
The following is a check list for the evaluation package for project 4 -