CSCI 160 Project (F21N01/N02)

Note: it is possible (perhaps even probable) that we will find some ambiguities or omissions in the project specifications. If this should occur, corrections will be posted as soon as possible and a note will be placed here outlining the changes. Please check back periodically for updates.

The specifications for the project (given below) detail the required behaviour for the project, but students are free to go beyond those requirements, and have much greater latitude for creativity. Your code must still adhere to the 160 code standards, but the design and implementation is otherwise left up to the student.

The project is due at 9pm on December 10th, and subject to the same late penalties as the course labs.

To obtain the project repository (where all your project work will be carried out and which you will need in order to submit), we'll follow a process similar to that used in the labs:

From your home directory in your linux account, run the command
make -f make160 csci160/project

Within your csci160/project directory you will find a project.cpp file and a makefile. All your project code must be in the project.cpp file.

Submission of the project must be done using
make submit
which must be done from within the project repository (just like with the labs) - no other form of submission will be accepted.

Specifications

The project this semester is to create a program that checks for timeline anomalies in character births and deaths. Suppose we have a game in which many NPC characters are born and die during the course of the game, and that the game keeps track of each of these events. Now suppose that time travel is rare but possible within the game universe - thus some NPCs can die "before" they are born. Now let's add one more complication: there is an alternate universe with some limited crossover possible between the two (apologies, I just realized this sounds terribly Marvel-y).

Our program is just concerned with examining the births/deaths in the two universes, looking for anomalies - characters who death date is earlier than their birth date within a timeline, and characters who are born in one universe but die in the other.

The user input for the program will just be a series of descriptions of births and deaths, with the following exact format for each entry:

• the date, expressed using a real number for the year, e.g. 2021.835 (we'll assume no two events take place at the exact same time)
• the name of the universe, either "original" or "alternate"
• either the word "birth" or "death" to signify the kind of event
• the unique name of the character as a single word, with underscores in place of whitespace, e.g. "Doe_J" (we'll pretend no other character in either universe has the same exact name)

Once the program has read the "END_OF_TIME" string, it will display a list of all the anomalies found: identifying which cases involved crossovers between the two universes and which involved time anomalies. (Note that it's possible for a case to be both: someone travels backward in time and switches universes.)

An example of user input is shown below, with one anomaly (Claire_R dies before being born)

207.9 alternate birth Mordecai
367.1001 original birth Chris_R
370 alternate birth Bric
373.0 original death Claire_R
389.41 original birth Jill_V
472.013 original birth Leon_K
490.4 original death Chris_R
491.74 alternate death Bric
493.2 original birth Claire_R
END_OF_TIME

Aside: this problem is actually closely related to one that must be solved by compilers on a regular basis. The compiler has to decide how and when to create and delete memory storage for each data item used in a program: variables, parameters, constants, etc. As it goes through a code segment it must identify where the item first needs to be created and where it is last needed, it must check that the program doesn't attempt to use or destroy something that hasn't been created, and it must check that the program doesn't create something that never gets destroyed. If we consider the introduction of namespaces, then as a debugging aid for the program the compiler might also want to spot cases where the programmer accidentally attempts to create or destroy something in the wrong namespace.

Additional specifications/requirements

1. The program must compile cleanly (no warnings/errors) using the -Wall and -Wextra options with our g++ compiler.

2. The program must run successfully in a terminal window on otter (csci.viu.ca), i.e. no opening new/graphical windows. If you wish to experiment with some extra control of the terminal display (colours, moving the cursor around the window, detecting keypresses, etc) you may #include and use the effects.h code that has been included within the project repository.

3. The program must not require the user to install any new software or libraries in order to run (e.g. no use of things like Boost). You are permitted to use the standard C and C++ libraries (e.g. cstdio, cmath, cstdlib, iostream, iomanip, string, etc)

Beyond those specifications, you are free to design and create the program as you wish, and to make the program output as simple or as fancy as you wish, and as robust as you wish with respect to error checking and handling. (The core mark for the project will be based on valid user input and basic output, but bonus marks will certainly be considered for advanced error checking and/or output.)

Design hints and help

Just before the study break (Nov. 6-14) design ideas for the project will be discussed in one of the lecture sessions, and at that time the instructor will post some video hints/discussion as well.

Arrays, sorting, strings, and null-terminated character arrays will all be useful (and possibly necessary) items, but you are welcome to use structs, classes, or other constructs as long as they don't violate any of the other project specifications/requirements.