EECS268 : Lab3

EECS268:Lab3
Overview
You will create a mock CPU scheduler. Programs will get in a queue and wait for their turn to have some time in the processor. While a program is using the CPU it call do simple things like add a function to its call stack. You will need to implement the provided Queue and Stack Interfaces and design and implement any additional classes needed (e.g. an Executive class).
Input from a file (name given at command-line) will dictate the order the programs are loaded into the queue and what any program is doing with its CPU time.
File overview
The input file you receive at the command line will consist of the commands listed below. After each command is executed display appropriate output to terminal.
If a command is impossible (e.g. calling a function when no processes are in the queue) display an appropriate error message.
COMMAND    Details
START <process name>    A new process is created and added to the queue. All processes start with a "main" as their first function call. Print a message to the screen indicating which process was added to the queue.
CALL <function name>    The process at the front of the queue gets some CPU time and calls a function. This put that function on the call stack for that process. After the call is made, that process goes to the back of the line. Print a message to the screen indicating which process called the function and what the name of the function is.
RETURN    The process at the front of the queue has the function at the top of its call-stack return. If the process has any functions left on the call-stack, put it at the back of the queue. Otherwise, if its main returns, simply remove it. Should a process end, display a message indicating this.
Example File
START itunes
START firefox
START putty
CALL play
CALL navigate
RETURN
Note this file would then display the following process list:
itunes added to queue
firefox added to queue
putty added to queue
itunes calls play
firefox call navigate
putty returns from main
putty process has ended
Stack Interface
Link to source for StackInterface.h
//  Created by Frank M. Carrano and Tim Henry.
//  Copyright (c) 2013 __Pearson Education__. All rights reserved.
//  Modified (JRM): throw exceptions instead of return bool success codes

/** @file StackInterface.h */

#ifndef _STACK_INTERFACE
#define _STACK_INTERFACE

#include "PrecondViolatedExcep.h"

template<class ItemType>
class StackInterface
{
public:
   /** Virtual destructor allows concrete implementations to clean up
       heap memory when the Stack is discarded. */

   virtual ~StackInterface() {}

   /** Sees whether this stack is empty.
    @return True if the stack is empty, or false if not. */

   virtual bool isEmpty() const = 0;
   
   /** Adds a new entry to the top of this stack.
    @post If the operation was successful, newEntry is at the top of the stack.
    @param newEntry The object to be added as a new entry.
    @throw PrecondViolatedExcep if no memory available for the new item */

   virtual void push(const ItemType& newEntry) throw (PrecondViolatedExcep) = 0;
   
        /** Removes the top of this stack.
        @pre The stack is not empty.
    @post If the operation was successful, the top of the stack has been removed.
    @throw PrecondViolatedExcep if the stack is empty when called */

   virtual void pop() throw (PrecondViolatedExcep) = 0;
   
   /** Returns the top of this stack.
    @pre The stack is not empty.
    @post The top of the stack has been returned, and the stack is unchanged.
    @return The top of the stack.
    @throw PrecondViolatedExcep if the stack is empty when called */

   virtual ItemType peek() const throw (PrecondViolatedExcep) = 0;

}; // end StackInterface
#endif
NOTE: This uses a custom type of exception called PrecondViolationExcep, but all of its code is provide. PrecondViolationExcep.h and PrecondViolationExcep.cpp
Queue Interface
Link to source for QueueInterface.h
NOTE: This uses a custom type of exception called PrecondViolationExcep, but all of its code is provide. PrecondViolationExcep.h and PrecondViolationExcep.cpp
//  Created by Frank M. Carrano and Tim Henry.
//  Copyright (c) 2013 __Pearson Education__. All rights reserved.
//  Modified (JRM): Use Exceptions

/** Listing 13-1.
 @file QueueInterface.h */

#ifndef _QUEUE_INTERFACE
#define _QUEUE_INTERFACE

#include "PrecondViolatedExcep.h"

template<class ItemType>
class QueueInterface

{
public:
   /** Virtual destructor allows concrete implementations to clean up
       heap memory when the Queue is discarded. */

   virtual ~QueueInterface() {}
   /** Sees whether this queue is empty.
    @return True if the queue is empty, or false if not. */

   virtual bool isEmpty() const = 0;
   
   /** Adds a new entry to the back of this queue.
    @post If the operation was successful, newEntry is at the back of the queue.
    @param newEntry  The object to be added as a new entry.
    @throw PrecondViolatedExcep if no memory available for the new item */

   virtual void enqueue(const ItemType& newEntry) throw (PrecondViolatedExcep) = 0;
   
   /** Removes the front of this queue.
    @post If the operation was successful, the front of the queue has been removed.
    @throw PrecondViolatedExcep if the queue is empty when called */

   virtual void dequeue() throw (PrecondViolatedExcep) = 0;
   
   /** Returns the front of this queue.
    @pre The queue is not empty.
    @post The front of the queue has been returned, and the queue is unchanged.
    @throw PrecondViolatedExcep if the queue is empty when called */

   virtual ItemType peekFront() const throw (PrecondViolatedExcep) = 0;
}; // end QueueInterface
#endif
Rubric
•    30pts Modularity
•    Sensible class design
•    Completely object oriented (e.g. your main should invoke some kind of executive class)
•    40pts Runtime functionality
•    Compatible with the provide format
•    You may assume the file will be formatted correctly with a series of commands that can be executed in the order given.
•    Well formatted output
•    10pts Stability
•    There should be zero segfaults
•    NOTE: You can assume a properly formatted file
•    10pts Memory leaks: There should be no memory leaks. Use valgrind ./YourProgramName on the cycle servers to verify
•    Any memory leaks will result in a loss of all 10 points!
•    Your destructors will play a key role in preventing memory leaks
•    10pts Comments and documentation:
•    @author, @file, @date, @brief (the author, file name, current date, and a brief description of a file) at the top of every file!
•    @pre, @post, @return, (Pre conditions, Post conditions, Return descriptions) in header files. Not required for cpp files
•    NOTE you don't need to comment the Makefile
Remember, if we type "make" into the console and your program fails to compile, we do not grade it.
Submission instructions
Send a tarball with all the necessary files (*.h, *.cpp, and makefile) in a tar file to your GTA email. Do not include any object (*.o) or executable file.
Creating a File Archive Using Tar
The standard Unix utility for created archived files is tar. Tar files, often called tarballs, are like zip files.
1.    Create a folder to hold the files you will be sending in. The folder should be named like LastName-KUID-Assignment-Number:
mkdir Smith-123456-Lab-0#
2.    Now, copy the files you want to submit into the folder:
3.    Tar everything in that directory into a single file:
tar -cvzf Smith-123456-Lab-0#.tar.gz Smith-123456-Lab-0#
That single command line is doing a number of things:
•    tar is the program you're using.
•    -cvzf are the options you're giving to tar to tell it what to do.
•    c: create a new tar file
•    v: operate in verbose mode (show the name of all the files)
•    z: zip up the files to make them smaller
•    f: create a file
•    Smith-123456-Lab-0#.tar.gz: the name of the file to create. It is customary to add the .tar.gz extension to tarballs created with the z option.
•    Smith-123456-Lab-0#: the directory to add to the tarball
Please note that it is your responsibility to make sure that your tarball has the correct files. You can view the contents of a tarball by using:
tar -tvzf filename.tar.gz
Emailing Your Submission
Once you have created the tarball with your submission files, email it to your TA. The email subject line must look like "[EECS 268] SubmissionName":
[EECS 268] Lab 0#
Note that the subject should be exactly like the line above. Do not leave out any of the spaces, or the bracket characters ("[" and "]"). In the body of your email, include your name and student ID.