Instructions for Laboratory #2 Assignment -- COM1201 W2000 -- Professor Futrelle

The lab is Thursday, February 10 and due on Tuesday, February 15, at the beginning of class.

This first explains the general goals of the lab, then the specifics, and finally the mechanics of just what needs to be handed in.

The general goals are for you to:

• Understand key-based sorting of records.
• Understand sorting problems such as stability.
• Build a simple "vanilla" application in C++.
• Decompose a project into appropriate files.
• Organize your project so the code and results are clear and clearly explained.
• Have a chance to design your own data records and adapt working code to deal with them.

More specifically, you are to do the following:

1. Design the records you want to use. It would be a good idea to do this in advance. Every student in the class must use a distinct record design.
2. Build and run a simple console project using the code that I have written. Be sure to have the medrecordbase.dat file in the same folder as your project and source code. See the Lab2 web pages for more on how to do this.
3. Start modifying my code by adding your class and adding the various reading and printing functions for your classes. By choosing slightly different names, you can do the additions without having to delete anything that I wrote, so you can keep them around for reference. When you're all done and everything works, you can delete my classes and functions from the source file (.cpp) file to clean it up. Of course you can toss my stuff earlier if you want; it's up to you.
4. You should design and carry out a systematic set of tests. I'd suggest something like the following.
   • Use a data file with short strings and numbers for easy print-out for testing.
   • Show that the sort works on at least two distinct fields, one a number and the other a string.
   • Sort a set of records twice, by two different fields to check stability. Be sure to design records that will sort differently by a stable versus an unstable sort.
   • Write the sorted records to files, along with a metadata line that explains what field the sort was based on and whether it represents a second sort of the same sequence.
   • Once things are working well, create a new version of your project with three files: One header file, one file of definitions, and one client file with main().
   • Grab your input and output data for pasting into your writeup.
5. Comment your code. Some comments should be grouped before a class or function, others might be at the detailed code level. Please don't put one comment for every line of code. Use better judgement than that.
6. Work on the documentation of your project, which should include what you did, how you did it, what your results were, and most importantly a discussion of your results, and conclusions. Results don't "speak for themselves"; they must be explained to be worth anything.

Some of the logistical details:

• Build your project and files and work only on the hard disk. Floppies are for backup only. You should never be actively editing or otherwise using files that are on floppies.
• Work with a pair of labeled floppies. Hand in one and keep one.
• It's most important to back up source and data files. The rest can be regenerated by the IDE.
• Collaboration: You're more than welcome to work with other people on your project, BUT: The work you hand in must be distinct from the work that anyone else hands in. The function names, variable names, comments, input data, record design, etc. must all be different. What you can collaborate on is ideas and strategies, debugging, questions of C++ syntax and style, etc. You can have another student read your code or writeup and critique it, giving you general suggestions as to how it might be improved. Collaboration should not be closer than that just described. Every quarter, a few students get zeroes (big "oh's") for overstepping the bounds and not doing their own work. Let's cut that number of students to zero in this course.

What to hand in. (Keep this in mind as you work on your project.)

• I will give you manilla envelopes in which to put your floppy and hardcopies.
• Your floppy should have all your project files, source files, and data files -- everything but the Debug folder and its files.
• Hand in hardcopies of source code listings for all ".h" and ".cpp" files.
• Hand in a writeup that includes, as appendices, your input data and output demonstrating the sorting you did. You may need to add comments to these to make them clear. Of course all data includes a metadata line. That can help. Your writeup can be partially written early on, well before it's due. Writing parts of it early can often help guide your work.
• Hand in whatever you have finished at the beginning of class. To make sure you succeed in this, print out earlier versions of your code and writeup from a few days earlier or from work Tuesday morning. Please do not come to class with nothing and an explanation (excuse) that the printer didn't work or you lost your files. Print some things out early so we'll know that you were getting work done.
• If you can't complete your project by the deadline, or even if it won't compile, hand in what you have gotten done by the beginning of class. Then you'll get some credit for that with no late points deducted.
• You can continue to work on your project after Tuesday if you're having serious problems, but again, turn in what you have up to that point on Tuesday.
• And of course, ask Mr. Meda or me or the tutors for help. Ask early, not at the last minute.

Good Luck and enjoy the project!