MSCU Library changes

Due to some of the difficulties in developing our classes, I have decided to release my solution for the first 2 homework assignments involved in developing this class. It wasn't really my intent, and I would like to stick with the idea that the rest of the library be developed by the students. In releasing my version of the classes, I have decided to also standardize on some basic organization of the classes, and class files.

This document will address the changes in organization, and attempt to explain some of the reasons behind certain decisions. Review my version, and this document. If you already have these classes, you might find some changes you wish to make to your own classes. Please do so with caution, and as little as possible. In other words, do not throw away your code.


File organization
The version of the library this document addresses defines the MSCUObject, MSCUDate, and MSCUSSN classes. For organization purposes, things have broken down to the following files:

File Usage
mscui.h Class definition of MSCUObject, and #include's for other .h files
mscuobj.cpp MSCUObject member functions
mscuidate.h MSCUIDate class definition (included by mscui.h)
mscuidate.cpp MSCUIDate member functions
mscussn.h MSCUSSN class definition (including all member functions) (included by mscui.h)

In the mscui.h file, you will find the #include statements needed for other classes, such as MSCUIDate. Part of my goal here, is to make so that you only have to include the mscui.h file to get full access to all classes. While this is convenient to the programmer, it causes longer compiler times, which I consider minimal, due to the size of our classes.


The Compare function
The Compare function defined by MSCUObject is given an MSCUObject& as a parameter in the base class. The comparison operators like operator== in the MSCUObject class invoke this function with a MSCUObject&. In order to have the derived class replace the MSCUIObject::Compare function, it must also take an MSCUIObject&. In otherwords, if you wrote MSCUDate::Compre to take a MSCUDate& as a parameter, and you were to give it an MSCUIObject& as a parameter (such as is found in the test program), then the compiler would opt to use the MSCUIObject::Compare function and not MSCUIDate::Compare.

This is because the type being passed by the MSCUIObject::operator== function is an MSCUIObject&, not MSCUIDate, and the compiler finds the nearest match in this case, the virtual function approach may not work as you would expect.

In order to word around this, the Compare function for the date (and any other MSCUIObject-derived class) is written so that it first makes sure that the data type it receives is an MSCUIObject&. Then, the parameter's type is checked against it's own datatype, using GetType. If the data types are different, an exception is thrown. If they are the same, the address of the MSCUIObject received by compare is type-case to a pointer to the correct type (MSCUIDate in the example below), and then the comparison is performed against that pointer. For example:
int MSCUDate::Compare( const MSCUObject& Src) const
{
if( GetType()!=Src.GetType() )
throw "Invalid type conversion";
const MSCUDate* pDate = (MSCUDate*)&Src;
if( Y!=pDate->Y )
return( Y - pDate->Y );
if( M != pDate->M )
return( M - pDate->M );
return( D - pDate->D );
}