CISC 3142 — Lab #4

CISC 3142
Programming Paradigms in C++
Lab #4
Part 1 Roundup

How to Develop and Submit your Labs

Make sure you read the sections in the above on how to interpret CodeLab string comparison feedback

Lab 4.1 — C++ Rational (Approval)

Overview

Like it says... the Rational class in C++. As before, I will be supplying a test program (rational_test.cpp) as well as an exception class (rational_exception.h). In addition, I am providing a partial rational.h to illustrate the proper parameter passing conventions used. You might want to not look at these files initially, and see if you can transliterate them yourself from the Java version I supplied, using the parameter transmission rules we discussed.

The basic specs are the same — the Notes section that follows contains language-specific differences. Any suggestions I provide are exactly that — suggestions. As long as you conform to the specs, and the CodeLab interface (see below), your are free to implement this in any manner you see fit.

The only additional function you need to write is a void print(ostream &os) const; member function that prints out the Rational. This replaces the toString of your Java implementation, and should have the same semantics.

Program Organization

While, normally, you would be free to organize your files as you see fit, I am providing a program organization you should follow — first, it's basically the organization you would use anyway (though you might have incorporated the gcd function into your Rational class -- I'm providing it here for you); second, the CodeLab implementation follows this organization and will complain if you deviate. You will be submitting rational.h and rational.cpp as two separate exercises in CodeLab. As I will be supplying the other, the function signatures in the .h and .cpp files must match (which is the purpose of this — to force you to use the correct signatures). All the function definitions (bodies) should go into the .cpp, i.e., none should be coded inline in the class declaration in the .h.

Notes

Submitting to Codelab

As in Labs 3.2 and 3.3, this lab is broken up in CodeLab into multiple 'subexercises': I had originally planned on allowing you to code the function signatures in any manner (as long as the resulting implementation 'worked'), but given that the correct signatures are more than simply 'good suggestions', I think we should enforce them from the very beginning.
A Word About the Compiler Feedback in CodeLab
In all likelihood, you will make a mistake on at least one function signature (by mistake I mean not matching my corresponding signature in the corresponding h / .cpp file; it may also be the case that I made a mistake in the signature). In the event of such (interface) errors, the compiler will complain about the two functions signatures not matching. In order for you to figure out your error, you should know which signature is your and which is mine, and where the compiler will be doing the complaining. In 4.1.1, the compiler will encounter the .h file first (because the #include is encountered at the top of the .cpp file), and thus the error will be manifested when it reaches my signature in the .cpp which won't match. Conversely, in 4.1.2 — where I am providing the .h file, the error will again appear in the .cpp signature, which is yours this time.

This exercise addresses many of the topics covered in the 'Preliminaries' lectures, this time in C++
  • Constructor overloading
  • Scoping, in particular class scope
  • Leveraging functionality, and maintaining semantic consistency
  • Mutable vs immutable semantics and methods
  • Asymmetric operands (receiver vs argument) in methods corresponding to binary operations
  • One and two argument operations

Lab 4.2 — Transcript: Using the STL

Overview

This assignment has you working with the vector container of the Standard Template Library (STL). The program is an extension of an upgrade of Lab 1.2 (which we present below).

Some Background

The purpose of this exercise is to introduce you to some of the higher-level facilities that were overviewed in Part I. Since this was an overview, many of the working details are deferred to the more detailed chapters in Parts II and III. To help flesh out some of those details, I've rewritten Lab 1.2 to provide you with a role model for this lab. I've taken the basic — almost C-like — language features presented in Part II — and used in Lab 1.2 — and replaced them with the higher-lever features and abstractions that will be presented in Part III.

Here is a link to an 'improved' (higher level) implementation of Lab 1.2 (Reading, sorting, and writing names).

This lab expands on this; in addition to changing the person class into a Student class, it introduces an additional Course class. If we had covered inheritance already (we just touched on it), we would make Student a derived class (i.e., subclass) of Person; instead, we'll simply use Person as a starting point and create a whole new class for Student.

The Details

Assume the file students.dat contains student transcript in the following format:
id	name
course_code	credits	grade
…
-1
id	name
…
for example:
143	Jones
1234		2	C
-1

123	Smith
4321		4	A
132		3	B
-1
(Note the formatting is for readability, everything could have been placed on one line; do NOT use getLine or any other line-oriented I/O; rather use token-orieinted I/O, e.g. >>).

Write a program that reads in the students, calculates their GPAs, and print out their transcripts in GPA order:

143 Smith: 3.57143
        4321 (4 credits): A
        132 (3 credits): B
143 Jones: 2
        1234 (2 credits): C

2 records processed

The Implementation

You will be submitting this to CodeLab, which will be enforcing the following program organization:
  • You should have two classes and an application file:
    • course.h A Course class that represents an individual course, the course code, credits and grade. The behavior (member functions) include getfunctions for the data members, a constructor, and a print function, with the same signature as the one you wrote for Rational.
      • Here is the inline << operator to allow you to directly print a course using cout << course:
        inline std::ostream &operator <dd<(std::ostream &os, const Course &course) {course.print(os)C; return os;}
        				
        • place the above immediately after your class declaration in course.h
      • Since the functions are all relatively simple, we can place them all inline in the class declaration proper, eliminating the need for a course.cpp file (not that there's anything wrong with having a .cpp file; I just want you to see as many variations as possible). Alternatively, you can simply have the headers in the class declaration and place the function bodies after the class declaration (still in the .h file) — but then you need the inline keyword (and don't forget the scope resolution operator in front of the function name, since it;s not strictly within the class declaration).
    • student.h/student.cpp A Student class that represents a student. This is similar to the Person class above, but also maintains a vector of Course objects. The behavior is a constructor, get functions to access the data members, and a getGPA that calculates and returns the student's GPA (this is not strictly speaking a get function as it is not merely accessing a data member; rather it's doing a calculation. There should also be the usual print function, and as you're all seasoned hackers and code pirates by now, YOU write the << on your own (I will be available for consultation if you get stuck).
      • Since print and getGPA are more than single-liners (they involve iterating through the vector), we are splitting this class into .h and .cpp files
    • app.cpp the application file. The application should declare a vector of Students, fill it from the data file, sort it by GPA, and then print the output.
Guidance for all of the above functions can be found in the improved Lab 1.2 example discussed above in the 'Some Background" section. Feel free to list as much of the code I present there, and use it as your own starting points.

Submitting to CodeLab

CodeLab is expecting your program to be submitted using the file organization described above and will enforce that organization.

  • Preliminary practice using STL containers and algorithms
  • Some more class practice
  • Some hints at operator overloading
  • Separate compilation

Code Used in this Lab