CSCI 161 Project

CSCI 161 Project (M23N01)

The project is intended to give students a chance to design and develop a somewhat larger program on their own, rather than following the rather structured design and implementation approaches given for smaller problems in the labs.

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 161 code standards, but the design and implementation is largely left to the student.

The project is due at 8pm on July 30th, and is subject to the same late penalties as course labs.

The project must be completed as a strictly individual effort: no team or collaborative implementations are permitted.

Project specifications:

overview
The objective for the project is to create a simulation that implements and uses a linked list (really more of a queue), with an appropriate decomposition into classes and functions and spread across multiple .h/.cpp files.
The choice of simulation area and kinds of data to track during the simulation are left to your discretion, but suggestions include:
- customers waiting for service (e.g. at a bank, or waiting for an online help rep)
- messages waiting to be read
- jobs waiting to be printed
- programs waiting to be run
- sequence of moves in a chess (or other) match
For your choice of simulation you'll need to select at least two pieces of information to be kept for each item in the queue (e.g. customer name and type of help needed, message sender and content, print job id and size, etc).
Your simulation needs (at least) to let the user repeat the following until they choose to quit:
- add a new item to the front of the queue
- remove the front item from the queue, display its data, and delete it
- cancel an item in the queue (e.g. to represent a customer leaving, a job getting cancelled, etc)
- print the entire queue contents from front to back
- search the queue to see where a specific item is in line (first, second, third, etc, or possibly not present at all)
- quit (end the simulation, delete all queue content)
(If you're stuck for an organizational structure, feel free to use the approach from applications.h/.cpp in lab2.)
data structures/organization
The project content is divided into six files:
- data.h/data.cpp provides the class/methods for an individual item: to set the data fields for a message (or client, or job, or ...), to print the message data, any needed construtors, destructors, overloaded operators, or other methods, etc
- datalist.h/datalist.cpp provides the class/methods for the linked list/queue of data items: e.g. methods to insert, remove, search, any needed construtors, destructors, overloaded operators, or other methods, etc
- project.h/project.cpp provides the main routine and any additional classes, methods, and functions for the user-interaction side of the project
implementation requirements
While you are free to add additional fields, methods, functions, etc, there is a core definition and set of methods for the data class and datalist class that you must provide implementations for:
- Required public methods in the data class (data.h/.cpp):
```
      data();        // default constructor
     ~data();        // default destructor
      void print();  // display the data item
      void fill();   // fill the data item from user input
```
  You will also be required to provide a copy constructor for the data class and to overload the assignment operator for the data class (simply using the default versions is not considered to meet this requirement).
- Required node structure, fields, and public methods in the datalist class (data.h/.cpp):
  The datalist is to be built as a linked list of lnodes (see below), where each node's data field consists of a pointer to an object of type data (from the data class).
  This particular linked list class has one slightly unusual feature: in addition to tracking the front/back of the list it also keeps track of a "current" item. This is the item that has most recently been accessed, with methods that allow setting current to point to the front or back of the list and to step forward/backward in the list one node at a time.
```
   private:
      struct lnode {
         data* d;       // application data to be stored for the node
         lnode* after;  // ptr to neighbouring node closer to the front
         lnode* before; // ptr to neighbouring node closer to the back
      };

      lnode* front;
      lnode* back;
      lnode* current;

   public:
      datalist();  // default constructor (empty list)
     ~datalist();  // default destructor (deletes all lnodes)

      void jumpFront(); // sets current to point to front
      void jumpBack();  // sets current to point to front
      void stepFwd();   // steps current one node toward back (no effect if already at back)
      void stepBack();  // steps current one node toward front (no effect if already at front)

      void replace(data *d);  // replaces current node's data with d
                              //    (has no effect if current or d is null)
      void display();         // displays data content of current node
      void insert(data *d);   // inserts new node at back (no effect if d is null,
                              //    sets current if the list was previously empty)
      data* remove();         // removes and deletes front node, returns its data pointer
                              //    (simply returns nullptr if list was already empty,
                              //     nullifies current if resulting list is empty)
```
  You are free to add additional fields and methods to the class, but the core set listed here should be implemented as specified.
- reminders about design/standards
  Remember to read and follow the course code standards, as they specify many things beyond simply the code/style itself (readme, version control, attribution of work, etc).
Obtaining/submitting the project
The project will be obtained and submitted using our regular git processes, and (as always) this will be the only acceptable means of submission.
To fork/clone the project:
```
ssh -x csci fork csci161/project csci161/$USER/project
git clone csci:csci161/$USER/project
```
To compile/run the project:
```
make projectx
./projectx
```
To submit the project:
```
git add filename < - - for each of the .h/.cpp files you modify and the readme
git commit -m "some message"
git push
```
Repository organization
As mentioned earlier, the project repository is set up with a makefile, three .h files (data.h, datalist.h and project.h) and three .cpp files (data.cpp, datalist.cpp, and project.cpp).
You are required to appropriately divide your code across the files, following the model we've used for the course labs.
You can add additional .h/.cpp files, but if you do so then you will also need to modify your makefile and update your #includes suitably to compile them.