CIS 114                                                     Summer 2005


                         Program 3
        	         ---------

Credit: 100 Points. 
Due Date:  Friday, June 24th, 6:00 PM.
NO SUBMISSIONS AFTER SATURDAY 9:00 PM will be accepted.



1) Implement Mergesort/Merge as shown in the tapes or in your book.
There are many Web sites with Mergesort on them, and I can find
them too.  You MUST type in the code with your own hands, word by 
word.  (And understand it while you type it.)

Add trace messages that print out:
ENTERING RECURSIVE CALL before every call to msort (mergesort) and
EXITING RECURSIVE CALL after every call to msort (that is mergesort).

2) Write a function SHOWARRAY that takes as argument an array of
10 numbers and displays the numbers in one row.

3) Create an array MYDATA that contains the following numbers:
19 5 17 3 11 7 2 3 23 13.

4) Now put all the above together in one program as follows:
Call SHOWARRAY on MYDATA.  It should show exactly the above line.
Then call Mergesort on MYDATA.  Then call SHOWARRAY again on MYDATA.
Now the data should appear sorted.


NOTE:  Remember to write an external documentation describing
your program.  Assume that it is written for somebody who has
no idea about sorting.  Less than a page typed is enough.

Remember that every function should have some header explanation in the
internal documentation.  Even if you think it is obvious.



General Comments:

1) Your program should be documented, as you learned in previous classes.
Internal documentation:  Brief explanations within the C++ code.
External documentation:  A brief write up (under a page length) explaining
what the program is doing, how to run it and where the files are.

The external documentation must be typed and spell-checked.  I WILL take 
points off for obvious errors, like sentences that end in the middle.

2) Your program should be reasonably indented.  I WILL take points
off for "random" or completely missing indentations.

3) Your submission should contain working code.  Don't bother submitting
if there are compiler error messages.  You will not get any points
for something that does not compile.  

If you get part of it working you get partial credit.  If you get
all of it "almost working" but it does not compile, you get no
credit at all.  So... try to advance from one working version to
the next, adding functionality slowly.

5) Your submission should also contain several screen dumps that show that 
the program is working.  (Or working at least partially.)  I would say you
need about two examples of every option the user can choose.  

The burden of proof is up to you.  If you don't show an option, I will
assume it does not work.

6) I really prefer hardcopy submissions....  But, if you can't
(and most of you probably can't) send me ONE email with THREE attachments:

-- The C++ code
-- The screen dump (that shows that it works)
-- The external documentation.

7) The subject line should say:
CS 114, Program 3