The appointment book application you wrote to help keep yourself organized has enjoyed an unexpected popularity among your co-workers. Some are happily using it as you intended. Others have borrowed your header files to write applications of their own. Some of that group are not so happy. They've bombarded you with e-mail about various alleged shortcomings in the program. They are demanding more support, so they can write fancier applications. Unfortunately, your boss agrees. She wants your classes to be the basis for Windows applications that would do neat stuff like display a calendar page and clock, pop up appointment lists, and let the user point and click for various functions. You don't understand Windows programming, but fortutunately there are highly paid individuals who do. All you have to do it provide the right classes and functions that they can use. Of course, to know if you can support other programmers, you had better testing carefully with drivers of your own.
To be a good basis for other people's development, your programs need to be robust, correct, and flexible. For example, they will have to handle appointment information that includes fuller dates and times, and do a better job of error-checking the input, wherever it might come from (a file, a Windows dialog box, another program, etc.) For another thing, it would be impossible to say in advance how large or small the clients would expect the list to grow. It seems unavoidable that the appointment list will have to be reimplemented as a linked list using dynamic memory.
To help organize your work, we have identified three parts to the implementation. The first one, improving the Date class, will be the subject of an intermediate turn-in, May 3. The second step is implementing an interface which lets the client catch up the date, and retrieves all the appointments for one give 24-hour period. The third step is reimplementing the appointment list as a linked list. Parts two and three will not have a separate turn-in. You are free to ignore this breakdown and do the work in any order, except that by May 3 you have to be ready to turn in the new Date class and some related things.
Note that you are not developing a stand-alone application, but provide support programming in case someone else does. To test your code, you will need driver programs (which might end up looking like small applications of their own).
[added 4/2799] To debug your program, take advantage of tools such as the debugger in MSVC. To encourage your use of it, we will have debugger tips and a debugger worksheet for you to do and turn in (probably in quiz section Thursday May 6. Details and due date to be announced separately, not on this page.). Don't wait -- learn to use it now.
The new Date class needs to be able to handle more realistic dates and operations on
them than the old one. The dates read from the file (or wherever) may optionally
include the year. One operation to improve is dayPlus, which "adds" a
number of days to a date, resulting in a new date. Adding 1 to Dec. 31, 1999 should
give Jan. 1, 2000. Adding 7 to Feb. 22 should give March 1 as a result (except in
leap years, which the program should handle correctly! Did you know that 1900 was
not a leap year, but 2000 will be?). The program should work for any reasonable date
since the Gregorian calendar went into effect. The time of day, as hours, mins, and
seconds, can also be read from the file, and will be stored as part of the date
(there is no separate Time class).
When developing a large project, it is often helpful to develop and test parts of the project independently. To encourage and illustrate this methodology, we are giving you a datetest.cpp driver file, whose only purpose is to test the functions of the Date class. datetest.cpp contains a main function, so to use it you build a project (separate from your overall big project) and link the needed files together. datetest.cpp reads dates from a file or from the keyboard, adds a number to them, and echoes the result so the tester can see if they were processed correctly. hw4int.exe is a demo of this program. (Note that this driver does not read appointment files, as HW3B did, just lines with dates on them, for testing purposes).
To get you started, we are giving you a new appfile.h. You'll have to change appfile.cpp in order to read in streams with the new format (and to write out streams with the new format). We're also giving you the datetest.cpp file. If you change datetest.cpp for your own testing purposes, that's fine, but you will not be able to turn in a modified datetest.cpp, and your new date.cpp will have to run correctly with the original one we give you. We are not supplying a new date.h or date.cpp file. You can start from the Homework #3 versions of these, and will need to modify both and turn them in.
For details of the new data formats acceptable on the input, please see the comments in appfile.h. The format acceptable for a date entered from the keyboard is identical to the format for a date on a file.
Files to be turned in by Monday, May 3, 5:00pm: date.h, date.cpp, appfile.cpp
It will now be possible for a client to interactively "catch up" the appointment list to a future day. (Previously, this was done only when the program started and read the date line from the input file). For example, if the client inquires about July 4, the system will consider that today is now July 4, and provide a list of all appointments starting then (i.e., now) over the next 24 hours.
[revised 4/27] This interface is to be provided as a function which clients can
call. We will provide the exact
specifications of the function later. At a later date we will supply
a test driver for this, too, analogous to the datetest.cpp driver mentioned earlier.
This function is called dayList and you can see its outline in dayList.cpp
(header file dayList.h). The driver program is main.cpp. The driver reads a text data file and does
things such as ask a user to enter data (such as a date) from a keyboard, write an
appointment file, etc., so it operates as a small application which uses the functions and
classes you provide. An executable version of this driver is in hw4.exe.
In dayList.cpp and main.cpp you will find a number of familiar functions that
should be useful, and should't need any modifications. Take a look before you go too
far!
[added 4/27/99] Studying main.cpp should give you further insight into how some of the other functions need to operate. You can add additional functions to the main.cpp user interface, either for your own test purposes, or to make a nicer user interface. But the operations already supported should not be changed; they should work exactly as they do in the sample executable.
[added 4/47/99] C++ allows only one function named "main" in a program. If you have more than one driver, you have to create a separate project for each one in MSCV. But they can use the same source files. You don't have to make duplicate copies of the .cpp files, one per project. You will probably have a least two projects, one for datetest.cpp and one for main.cpp. You may also find it useful to write additional simple drivers of your own. For example, the main for Homework 3, with just a few changes (and perhaps some supporting changes in the functions it calls) could be used as another test driver.
The AppointmentList ADT is to be reimplemented using linked lists to store the list appointments. (It is OK to continue to use fixed-length character arrays to hold string data, but if so you need to make sure such arrays never overflow, regardeless of what data a client may pass in). The client interface to the list should remain the same. If you find it useful, you may borrow linked list code from the textbook (please acknowledge the borrowing in a comment).
[clarification 4/27/99] The linked list is to be implemented with dynamic memory. Your class should have the full suite of dynamic memory utilities: a copy constructor, an overloaded assignment operator, and a destructor.
You may find that some minor changes are needed to the Appointment class itself.
Use asserts liberally throughout the code. When practical, test preconditions, postconditions, loop invariants, class invariants and constraints, and any other sort of condition which might help check the correctness of the computation. Remember that pointer and array bounds errors can manifest themselves in bizarre ways, so even checks for "impossible" conditions can help catch bugs.
With respect to errors in the input, include code to detect the errors and recover gracefully, rather than giving an assertion and ending the program. This time, your final version of the input handling should be quite robust. Please give us two data files: one with non-trivial, good data, and another one with errors that your program can successfully recover from.
Files to be turned in by Monday, May 10, 5:00pm (tentative list): date.h, date.cpp, appfile.cpp, even if these did not change from the previous turn-in. Also, give us appfile.h, appointment.h, appointment.cpp, appointmentlist.h, and appointmentlist.cpp. There will probably be open slots on the turn-in form for up to two addtional .h and two addtional .cpp files. Also, turn in the two data files mentioned above, one good and one bad.
Print out and staple the turn-in receipt. Give it to your TA in quiz section (unless you have made arrangements otherwise).
Staple to the front the usual three reports. 1) what works and what doesn't; 2) design critique and 3) statement of acknoweldgements and help recieved.