Please see the general programming webpage for details about the programming environment for this course, guidelines for programming style, and details on electronic submission of assignments.

Collaboration Policy

For this assignment, you must work individually in regard to the design and implementation of your project.

Please make sure you adhere to the policies on academic integrity in this regard.

Contents:

• Overview
• Files We Are Providing
• Files to Submit
  • Source Code
  • Test Input
  • Readme File
• Using Our Driver
• Grading Standards

Overview

Our goal for this assignment is to maintain lists of integers which are sorted in non-decreasing order. In particular, we focus on an operation for merging two such lists while ensuring that the data is sorted in the combined result. Conceptually, the merging process is simple precisely because the two original lists are internally sorted.

You will be writing a method merging two such lists, represented as doubly-linked lists with header and trailer sentinels, as in Ch. 4.5. Specifically, we provide a class SortedList to create and represent such lists. The source code for the entire project is already complete, with the exception of a single routine which we ask you to implement. The class definition for the SortedList class includes the following method declaration.

  /**
   * Removes all elements from list 'that' merging the nodes into the
   * current list 'this', while maintaiing the invariant that the
   * elements are sorted.
   */
  void merge(SortedList* that);

So all you have to do is to turn this idea into working code. Before writing your code, think about how you will accomplish this. It may help to consider the process you might use if physically manipulating objects, such as two groups of books. You might imagine placing one finger at the beginning of the first list and one finger at the beginning of the second list. Now, you should be able to advance the pointers in a way, ensuring that items are moved from the second list into the proper place in the first list as you go. If you are having trouble as you go, always think about if a bug could be fixed by simplifying your code before you decide to expand your code. There exists a remarkably simple solution to this assignment.

In fact, the merging process is described on page 491 of the text, due to its role in the larger context of designing an algorithm for sorting a group of elements from scratch. You may skim that material in the book for general guidelines regarding the merging process, however the implementation details for this assignment vary greatly from that coverage in the book. In particular, the description in the book creates a third list as the result, rather than directly reogranizing the items in the original lists. Furthermore, the algorithm in the book is described using the Sequence ADT rather than by directly manipulating a low-level linked lists as in this assignment.

Files We Are Providing

All such files can be downloaded here.

• Node.h
  This provides a definition of a class Node and typedef NodePtr, almost identical to those given in Code Fragment 4.23 of the text. The differences between our definition and that of the book are:

  • We have explicitly typed the element as an int rather than templated as an Object.
  • We have intentionally made the constructor private so that you are unable to create new nodes, and thus are forced to reogranizing the existing nodes.
  • In similar fashion, we have explicitly disallowed your ability to alter the value of the element field.

• SortedList.h
  This provides a class definition for a very streamlined doubly-linked list. The only data members are the two NodePtr's representing the header and trailer sentinels.

  Most likely, you should not be making any changes to this file. You are not to introduce any additional instance variables. The only possible modificaiton which we forsee is if you wish to introduce any private utility functions while implementing the merge method. If so, you would need to declare those utility methods within the class definition.

  Please note that we provide the constructor which builds the original lists based on user input via a driver; you do not need to be concerned with this constructor.

• SortedList.cpp
  This is the one file which you surely must modify It contains a stub for the SortedList::merge method, yet without any code.

• MergeTest.cpp
  This file provides a main driver to be used in testing your program. You will not need to modify or examine this code. The use of the driver is discussed later in this assignment description.

• ListReader.h, ListReader.cpp
  These files define a class for building the original lists in coordination with the driver. You will not need to modify or examine this code.

  One Warning: Remember that the lists include both header and trailer sentinal nodes. You should not make any assumptions about the 'element' value of those sentinels. To make sure that you do not rely on those values, our list constructor intentionally assigns random element values for the sentinel nodes!

• makefile
  This makefile should allow you to rebuild your project by simply typing 'make' rather than in invoking the compiler directly.

Files to Submit

• SortedList.cpp
  We expect that this is the only file you will modify, but if this is not the case, please submit any additional such files.

• Test Input
  Please submit a single file, inputfile, which we will use as sample input when testing all of the students' submissions. The file format for inputfiles is based on use with our driver Your input file may use at most 100 lines (although you may certainly specify multiple merges within the 100 line limit). In order to make sure that your inputfile follows the proper format, we strongly recommend that you make sure that your inputfile is accepted by the driver.

• Readme File
  A brief summary of your program, and any further comments you wish to make to the grader.

Using Our Driver

The executable MergeTest is a driver which will handle reading the input, creating the initial lists, calling your routine, and then outputting the results. The merged list is then printed twice, once while traversing the list from front to back, once while traversing from back to front (in case inconsistencies exist in the doubly-linked list).

The expected format for input is as follows (please make sure that the inputfile you submit adheres strictly to these standards!):

• Each line is to contain a single integer.
• The end of a particular list is indicated by 1000.
• The final end of data is indicated by -1.
• All other integer values must be between 0 and 999.
• Each individual list must have elements entered in non-decreasing order.
• Duplicate values may appear in one or both of the lists. In this case, the final merged list will contain multiple copies of those particular values.
• The file is at most 100 lines.

You will notice that this format allows you to specify a test file which involves many different merges, as demonstrated in the following example of a properly formatted input file.

5
9
12
1000
4
10
11
15
1000
3
4
1000
1000
1
5
5
8
1000
2
8
10
1000
-1

The driver will create the two lists A = {5, 9, 12} and B = {4, 10, 11, 15}, and then call invoke method A.merge(B). Hopefully this results in A = {4, 5, 9, 10, 11, 12, 15}.

After that, it will create two lists A = {3, 4} and B = { }, and again call A.merge(B) (which hopefully results in A = {3, 4}).

Then it will merge {1, 5, 5, 8} and {2, 8, 10}, hopefully producing the list {1, 2, 5, 5, 8, 8, 10}. After this, it exits.

By default, the driver reads input from the keyboard. However, if you would like to have the driver read input from a text file, you may create such a file, and then give the filename as a single argument when starting the program (as was done in an earlier programming assignment).

Grading Standards

The assignment is worth 10 points. Eight points will be awarded based on our own evaluation of your assignment and the readme file. One additional point will be awarded fractionally based on how well your program performs on other students' test inputs. The final point will be awarded fractionally based on how well your test input fools other students' flawed programs.