This lab is due before seven days from the start of your lab.
• The header and cpp files of any other classes you make
In this lab you will be making an interactive course directory. You will read the information for several courses from file.
Each course will have a title and a set of students, represented by student IDs.
You will read in all the course information from file and then let the user interact with it in various ways.
The file will start by indicating how many courses will be in the file.
Each course follows the format of
• Department code
• Course number
• Number of students in the class
• List of student ids (5-digits with no leading zeroes)
EECS 268 5 12345 54321 68454 75984 15348
MATH 521 3 47896 41236 45826
BIO 101 4 96369 85525 14741 98754
Please note, when we test your program we will use new, larger, and more complex files than the sample one provided.
I encourage you to come up with your own test files.
The user will launch your program and pass in the file name containing the course data from the command line (recall argv and argc).
Once the file is read in, provide the user with a menu in order to do the following:
1. Print all courses
• The order they appear will be the same order they appeared in the file
• Print all course names (department and number) from the file
• Do not print student ids
2. Print all courses for a department
• Obtain a department code from the user then print all courses in that department
• When printing a course, print the department code and number
3. Print roster for a course
• Print all the student IDs for a course. Delimit the ids with commas
4. Print largest class
• Print the name of the largest class and the amount of students in that class
5. Swap two classes
• Obtain two class names (department and number) from the user and swap their positions in the catalog
• If all courses are printed after this, you should see that the two courses swapped positions
6. Print schedule for student
• Obtain a student ID from the user and print the names of all courses that student is enrolled in
7. Exit the program
In 268, your mains will be very concise, passing control to some kind of Executive class that will then run the show (example main below).
You need to think about how you represent a single entry from the file. Remember, we are making object oriented code, so you need to solve all the problems you encounter by using/create a class!
Things to think about:
• How can I represent a single course?
• What kind of data does a course have, and how will I access it?
• Remember, we’re not in the business of public member variables that house critical information
• What kind of information does a course need at construction time?
• What will contain all of the course?
• When swapping courses, what method needs to be defined for a course?
You’ll need a class (or classes) to handle other important things:
1. verify the file was opened
• You can assume if the file was able to be opened that it is formatted correctly
2. Reading the data from file and storing it
3. Present the user with a menu and handle the interactions
• Don’t assume the user is going to give you good input at the menu!
• Recall the cin failbit
4. Deallocate everything (e.g. any arrays or objects) when the Executive object is tossed out of memory
Your TA will introduce you the DDD/GDB debugger. It will allow you start your program and then step through the code as it’s running and watch how values are changing and what paths your code is taking.
I want to encourage you to use the debugger over shoving couts in random places in code to figure out what’s going on.
Main will be in charge of very little. It will include the needed files, but as soon as possible it will hand control over to the the Executive class.
You main can verify the proper number of command line parameter, but after that it should give control to the Executive class.
int main(int argc, char* argv)
if(argc < 2)
std::cout << “Incorrect number of parameters!\n”;
Executive exec(argv); //sample creation of executive object
exec.run(); //presumably handles the calling of all other member methods
Unless it your project is graded during the lab, send a tar file with all the necessary files (*.h, *.cpp, and makefile) in a tar file to your GTA email. Do not include any object (*.o) or executable file.
Creating a File Archive Using Tar
The standard Unix utility for created archived files is tar. Tar files, often called tarballs, are like zip files.
1. Create a folder to hold the files you will be sending in. The folder should be named like LastName-KUID-Assignment-Number:
2. Now, copy the files you want to submit into the folder:
3. Tar everything in that directory into a single file:
tar -cvzf Smith-123456-Lab-01.tar.gz Smith-123456-Lab-01
That single command line is doing a number of things:
• tar is the program you’re using.
• -cvzf are the options you’re giving to tar to tell it what to do.
• c: create a new tar file
• v: operate in verbose mode (show the name of all the files)
• z: zip up the files to make them smaller
• f: create a file
• Smith-123456-Lab-01.tar.gz: the name of the file to create. It is customary to add the .tar.gz extension to tarballs created with the z option.
• Smith-123456-Lab-01: the directory to add to the tarball
Please note that it is your responsibility to make sure that your tarball has the correct files. You can view the contents of a tarball by using:
tar -tvzf filename.tar.gz
Emailing Your Submission
Once you have created the tarball with your submission files, email it to your TA. The email subject line must look like “[EECS 268] SubmissionName”:
[EECS 268] Lab 01
Note that the subject should be exactly like the line above. Do not leave out any of the spaces, or the bracket characters (“[” and “]”). In the body of your email, include your name and student ID.
Grades will be assigned according to the following criteria:
• [20pts] Class Design
• Each class’ role should be well defined
• Avoid create “god classes” or classes that are in charge of way too much, break the problem down into several classes
• [10pts] Code documentation
• Header file comments (pre-conditions, post-conditions, and return value descriptions on every method!)
• [5pts] Readabilty of output and stability of interaction
• Check for bad type (e.g. check failbit of cin)
• Check for bad ranges on good types of input
• [55pts] User interactions
• [5pts] interaction 1
• [10pts] interaction 2
• [5pts] interaction 3
• [10pts] interaction 4
• [13pts] interaction 5
• [10pts] interaction 6
• [2pts] exiting
• [5pts] No segfaults (all or nothing)
• [5pts] No memory leaks (all or nothing)