Lab09, CISC181, Fall 2004

Background

Your Deitel/Deitel text sometimes functions like a textbook, but other times, it functions more like a reference manual. For this lab, the following sections may be useful as "reference" material.

Section 3.20 in Deitel/Deitel (Function overloading)

Part 1: (lab09a.txt) Copying files and checking your disk quota

Copy the files from the lab09 subdirectory into your own cisc181/lab09 subdirectory.

In addition, you should take this opportunity to check your disk quota on strauss.

Type "quota -v" at the Unix prompt. You'll see some numbers such as the following:

> quota -v
Disk quotas for pconrad (uid 53430):
Filesystem     usage  quota  limit    timeleft  files  quota  limit    timeleft
/scratch           0      1      1                  0      0      0            
/home/usra     12944  20240  20240               3417  76800  76800            
>

You need to compare the number listed under "usage" with the number listed under "quota". For example, in the listing above, the usage is 12944 (somewhere been 12MB and 13MB) and the quota is 20240 (20MB). This is good; this is about where you want to be.

If on the other hand, your usage is very close to your quota, you may run into lots of difficulties. Compling, editing, logging on and off of the Sun Ray servers—all of these operations may begin to fail or produce strange errors.

In this case, you need to clean up your disk space usage. Here are some useful commands which you should learn (and know for the next exam!)

> cd
> du -sh *
> du -sh .*

This sequence of commands changes directory to your main directory, and then gives you a list of all your files and directories in your main directory, along with a summary of the disk usage for each file or directory. The -s flag indicates that you will get a summary of all the disk space under a particular directory, while the -h flag indicates that you will get results reported in K or M, standing for Kilobytes (units of 1024 bytes) or Megabytes (units of a bit over a million bytes, 1024 x 1024 to be exact).

The * means "all directories and files", and the .* means "all hidden directories and files" (file and directory names that start with a . are "hidden files" under Unix. They don't normally show up in directory listings unless you do "ls -a").

A good candidate for deleting is your .mozilla cache directory. You should go into Mozilla or Netscape and set the size of your cache down to only about 4MB or so. While inside, you should also be able to clear out the cache and save a lot of disk space.

As a last resort, if you are unable to clear the cache from inside mozilla, you can type "/bin/rm -rf .mozilla" which gets rid of your entire mozilla subdirectory. You'll lose all your web shortcuts, but oh well. Type CAREFULLY! (With this command, if you accidentally leave a space between the . (dot) and the word mozilla, you could delete your ENTIRE ACCOUNT and all its contents. That would be bad.)

Another good candidate for deleting is your old "executable" files; a.out files, and any file you create with the -o flag from the compiler. They tend to be large, and once you've produced your script, you don't need them anymore; you can always bring them back any time you like by recompiling. But DON'T get rid of the source files (.cpp, .cc, .h. .dat, etc.) for your old labs; you may need them for future labs this semester! Only delete the exectuable files, and the .o files (ask your TA if you are not sure.)

To turn in: a script file lab09a.txt in which you run the "quota -v" command and show that your disk usage is at least 3-4MB less than your quota. That's the amount of "headroom" you need in order to effectively do programming work. If your usage is higher than that, use the "du -sh *" command to do some deleting. You do NOT have to script the deleting part; only the "quota -v" command showing the end result of your clean up needs to be in your script.

Part 2: (lab09b.txt) Function Overloading

The topic of "function overloading" is crucial to a discussion of classes, especially when it comes to understanding constructors, so this lab will emphasize that material from Chapter 3 to prepare us better for understanding classes.

The idea of function overloading is similar to the idea of "multiple senses of a word" in the English language. Consider the uses of the word "rose" in the following three sentences:

"That which we call a rose by any other name would smell as sweet."
"The committee rose from closed session at 2:03 pm"
"Eschewing feathers and elaborate costumes, singer/composer Elton John donned a black suit and rose-colored glasses for the premiere of his new production show The Red Piano at The Colosseum at Caesars Palace."

In one sentence, "rose" refers to a flower. In another "rose" is the past tense of "rise", and in the third, "rose" refers to a color. The word "rose" by itself is ambiguous—capable of having multiple meanings. We "disambiguate" the word by looking at the surrounding context.

In the same way, a given "name" in C++ can refer to different functions. We can "disambiguate" the word by looking at context. The main idea of "function overloading" is that in C++ (unlike in plain C), a programmer may include more than one function with exactly the same name in the same program. This is called "overloading" the function name. So, for example, you can define two (or more) different functions that are both named "squared". However, each of the versions of the function must have different parameters. This is how the compiler can distinguish between the different functions when you make a function call. Again, the technical term is "disambiguate"; the compiler is "removing the ambiguity" that is created by having multiple functions with the same name, by using context: in this case, the number and type of parameters.

If possible, review section 3.20 of your textbook before proceeding (if you don't have a textbook handy, you can still proceed with the lab, but you'll find it easier if you get a chance to look over section 3.20). You can find the source code for the program from Figure 3.25 of your text in the lab07 subdirectory mentioned in Part 0 of this lab (filename: fig03_25.cpp). Copy this file into your account and run it.

Then, write your own program that illustrates the principle of function overloading. Call your source code lab09b.cpp. Your program should include a main function, and three functions, each of which is named readInteger. Each of the functions should return an integer, but they will differ in the number of types of parameters:

The first one should take no parameters at all (i.e. it should have the following prototype:
```
int readInteger(void);
```
Inside that function, print a prompt on cout that says "Please enter an integer >". Read a value in, and return that value as the result of the function.
The second version of the readInteger function should take one integer parameter min, for example:
```
int readInteger(int min);
```
This function should read an integer from cin that is greater than or equal to min and return that value. It should prompt the user with a message like the following: "Please enter an integer >= 2", except that instead of 2, you should print out the value of min that was passed in.
This function should check the value entered by the user; if it is less than min, print an error message, and ask the user to enter the value again. Repeat this process until the user enters a valid value, and then return that value as the result of the function.
The third version of the function will take two integer parameters: min and max. The idea is the same as for the second version of the function, except this time, you are checking that the value is between min and max, inclusive. This time, its up to you to come up with the function prototype. Your function should provide an appropriate prompt, issue an appropriate error message if needed, and return only after the user enters a legal value.
Once you have written the three functions, write a main program that will test these three functions, and demonstrate that each of them works properly. If you aren't sure what is expected, you can use Figure 3.25 from Deitel/Deitel as a model.
Now, before you script, you are going to split your work into three separate files:
- The first file, readInteger.h, should contain only the function prototypes for your three versions of the readInteger function.
- The second file, readInteger.cpp, should do a #include on the readInteger.h file, and then contain the function definitions for the three versions of readInteger.cpp
- The third file, main.cpp, should do a #include on the readInteger.h file. It should then contain your main program, which callls all three versions of your readInteger.cpp program to show that they work.
- Finally, compile your files separately, as follows:
```
g++ -c readInteger.cpp
g++ -c main.cpp
g++ readInteger.o main.o -o main
```
Now, write a Makefile that contains an "all" rule that depends on the executable main, and separate rules for main, main.o and readInteger.o. The .o files should depend on the .cpp and .h files, and the exectuable main should depend on the .o files. Your Makefile should have a "make clean" rule as well.
Now, make a script lab09b.txt where you cat your source files main.cpp, readInteger.h, readInteger.cpp, and your Makefile (you don't need to worry about lab09b.cpp; that was just practice.) Then, do a "make clean" and a " make all" in your script, and then run your executable to demonstrate it. Run it as many times as is needed to show that all of your functions work properly. Then end your script.

Part 3: (lab09c.txt) A Complex Number Class in C++

Complete " lab exercise 1" from your white Deitel/Deitel/Nieto lab manual, p. 233-236.

Add code to the Makefile from Part 2 to also cover the files that you add in this part of the lab (i.e. add "complex" as one of the binaries in your "make all" rule, and add rules for complexm.o, complex.o, etc.)

Create a script lab9c.txt that has all the usual stuff. By now, you shouldn't need me to spell out for you all the details of what you need to do.

Submission and Grading

lab09a.txt	script of checking your disk quota	submit to webct and print for TA	10 pts	following instructions, having 3-4MB of "headroom"
lab09b.txt	script of overloaded functions (main.cpp, readInteger.cpp, readInteger.h, Makefile)	submit to WebCT and print for TA	35 pts	In each case: 15 pts: correctness of C++ code 10 pts: C++ style 5 pts: correctly scripting 5 pts: getting the Makefile right
lab09c.txt	script of Lab Exercise 1 on pp 233-236 of the lab manual (complex.h, complexm.cpp, complex.cpp, and your modified Makefile)	submit to WebCT and print for TA	35 pts
lab09.tar	A tar file of your entire lab09 subdirectory after doing a Make clean, and getting rid of anything else unnecessary	submit to WebCT	20 pts	Following instructions to create and submit properly.

Follow up:

For next week, there are no pre-lab exercises "due" because of the midterm exam. However, your pre-lab exercises for two weeks from now include completing the "follow-up questions and activities" on p. 236-237 of the lab manual, and these pertain to today's lab. So you might want to go ahead and get them done now.

Turn them in to your TA during the lab on November 17, 2004 along with your pre-lab exercises for Chapter 7. See ple07.html for other pre lab exercises due on November 17, 2004.