EECS268 : Lab2

EECS268:Lab2

This lab is due one week from the start of your lab.
Overview
In this lab you will create an implementation of a List and then use your implementation to simulate a web browser's basic functionality.
List Interface
#ifndef LIST_INTERFACE_H
#define LIST_INTERFACE_H
#include <stdexcept>
template <typename T>
class ListInterface
{
    
     public:
     virtual ~ListInterface(){}


     virtual bool isEmpty() const = 0;
     virtual int getLength() const = 0;
     virtual void insert(int position, T entry) throw (std::runtime_error) = 0;
     virtual void remove(int position) throw (std::runtime_error) = 0;
     virtual void clear() = 0;
     virtual T getEntry(int position) const throw (std::runtime_error) = 0;

     /** Here's an example of a doxygen comment block. Do this for all methods
     * @pre The position is between 1 and the list's length
     * @post The entry at the given position is replaced with the new entry
     * @param position:  1<= position <= length
     * @param newEntry: A new entry to put in the list
     * @throw std::runtime_error if the position is invalid.
     **/
     virtual void replace(int position, T newEntry) throw (std::runtime_error) = 0;
};

#endif
Notes on the interface:
•    All methods (minus the destructor) are pure virtual because your LinkedList class will inherit from this interface and provide definitions
•    Again, your LinkedList class will need to inherit from this interface
•    There are no member variables in the List Interface since those are always tied to implementation details.
•    The destructor can be virtual, but cannot be pure virtual so we leave an empty definition

Web Browser Simulator
You will create a program that mimics the behavior of your web browser. Since this in only a one week lab, browser won't have multiple tabs. You could think of it as a modern day browser without only one tab open.
Here is an interface for the WebBrowser. You may not change or add to this interface. You must implement this interface, satisfying all the requirements described.
Reminder Constructors and assignment overloading are allowed to be added to your WebBrowser classes, since they do not alter the interface's intended behavior.
Your implementation can then be used by an Executive class.
#include "ListInterface.h"
#include <string>

class WebBrowserInterface
{
  public:
  /**
  * @post All memory allocated by the implementing class should be freed.
  *       This, as with all virtual destrucors, is an empty definition since we
  *       have no knowledge of specific implementation details.
  */
  virtual ~WebBrowserInterface(){}

  /**
  * @pre none
  * @post the browser navigate to the given url
  * @param url, a string representing a URL
  */
  virtual void navigateTo(std::string url) = 0;

  /**
  * @pre none
  * @post if possible, the browser navigates forward in the history otherwise it keeps focus
  *         on the current URL
  */
  virtual void forward() = 0;

  /**
  * @pre none
  * @post if possible, the browser navigates backwards in the history otherwise it keeps focus
  *         on the current URL
  */
  virtual void back() = 0;

  /**
  * @return the current URL
  */
  virtual std::string currentURL() const = 0;

  /**
  * @pre The list being passed in is empty
  * @post The current browser history is copied into the given list  
  * @param destination, an empty list of strings that will have a copy of current history copied into
  */
  virtual void copyCurrentHistory(ListInterface<string>& destination) = 0;
};
Reading the history from file
Command to interact with your browser will come from a file. The file name will come in on the command line.

Browser Command    Description
NAVIGATE <URL>    Navigates the browser to the given URL. NOTE navigating to a URL retains all URLs accessible from going BACK, but any URLs that would have accessible from going FORWARD are now lost
BACK    A command indicating the web browser is redirected to the previous URL in the history. If there is no URL further back, then the browser stays on the current URL.
FORWARD    A command indicating the web browser is redirected to the next URL in the history. If there is no URL that is next, then the browser stays on the current URL.
HISTORY    Prints the current URL history to the screen using the following format:
Oldest
===========
<URL>
<URL>  <==current (assuming this is the current URL)
<URL>
===========
Newest
Sample input file
NAVIGATE http://google.com
NAVIGATE http://reddit.com
NAVIGATE http://facebook.com
NAVIGATE http://myspace.com
BACK
BACK
HISTORY
NAVIGATE http://bing.com
HISTORY
Output to screen:
Oldest
===========
http://google.com
http://reddit.com <==current
http://facebook.com
http://myspace.com  
===========
Newest

Oldest
===========
http://google.com
http://reddit.com
http://bing.com <==current
===========
Newest
Libraries You May Include
•    iostream
•    fstream
•    string
•    stdexcept
Vectors or any other dynamic data structure that you don't build yourself is forbidden!
Rubric
•    40pts Modularity
•    Sensible class design
•    Completely object oriented (e.g. your main should invoke some kind of executive class)
•    30pts 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. The exception of course for the forward/back commands.
•    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.