Instructions:
1. The declaration of the ReadingList class has been changed, in the private area, to use a std::list instead of an array as its implementing data structure.
Because a std::list can grow arbitrarily long, there is no need to pre-allocate a space to hold the books, so the parameters and function for tracking the capacity have been removed.
2. Your task is to follow through on that change, making the necessary alterations to readingList.h and readingList.cpp to make this a working class. The necessary changes have already been made to the unit tests and to the main mergeLists.cpp application.
3. The major difference between lists and the earlier sequential structures that we have looked at is that elements are accessed via iterators instead of integer-based indices. Accordingly, you will need to:
– Rewrite the indexing-based code in readingList.cpp with iterator-based code.
– Remove the indexing-based get function from readingList.h and add appropriate declarations of iterator and const_iterator types and associated functions allowing access to a ReadingList object’s sections.
4. To improve the usability of the ReadingList class, you will also need to add
– A constructor to allow ReadingList objects to be constructed from a pair of iterators denoting a range of Book values from some arbitrary container.
– A constructor to allow ReadingList objects to be constructed from an initializer_list of books.
5. Your code will be evaluated both on its ability to function correctly within the mergeLists application and on its ability to pass the various unit tests provided.
– In the test report, tests 0…7 test the mergeLists application. Tests numbered 8…25 check the unit tests.
– Each even-numbered test checks for correct behavior of the code.
– Each odd-numbered test checks to see if that same behavior is correct and entails no memory leaks or other common pointer/memory handling problems.
6. Submit files readingList.h and readingList.cpp
Problem Description:
This assignment centers on a program that accepts as input two lists of e-books (derived from Project Gutenberg) and merges the two into one, eliminating any duplicate entries during the process. Each e-book is is described by three fields, an ID, the author info, and the title. In input and output, these appear together on a line separated by tab (“t”) characters.
For example, given the input
etext19640 Twain, Mark, 1835-1910 Adventures of Huckleberry Finnetext13 Carroll, Lewis, 1832-1898 The Hunting of the Snarketext9038 Twain, Mark, 1835-1910 The Adventures of Tom Sawyerand
etext9038 Twain, Mark, 1835-1910 The Adventures of Tom Sawyeretext20595 Twain, Mark, 1835-1910 The Awful German Languageetext23717 Carroll, Lewis, 1832-1898 Jabberwockythe merge will be
etext13 Carroll, Lewis, 1832-1898 The Hunting of the Snarketext19640 Twain, Mark, 1835-1910 Adventures of Huckleberry Finnetext20595 Twain, Mark, 1835-1910 The Awful German Languageetext23717 Carroll, Lewis, 1832-1898 Jabberwockyetext9038 Twain, Mark, 1835-1910 The Adventures of Tom SawyerThe output is sorted by the project Gutenberg ID (the “etext…” field).
You are being supplied with a nearly complete working version of the mergeLists application.
Your task is to complete the implementation of the ReadingList class in accordance with the principles for robust and reusable ADTs as described in the lecture notes. You must use a dynamically allocated array as the basis for storing books within the reading list.
System Tests:
The program takes its input from two files named in the command line and produces its output on standard out (cout). For example, if you have compiled the program into an executable named “mergeLists”, and had saved the sample input above in files tinyList.txt and tinyList2.txt in the same directory, you could run the program as
./mergeLists tinyList.txt tinyList2.txtIf you are working in Windows, use “.” instead of “./”. Of course, if you have your files in different directories or use different names, you will need to adjust your paths in the above command accordingly.
In general, you are responsible for designing and running your own systems tests.
That said, you have been provided with several input files of various lengths that you can use “as is” or chop up and recombine as you see fit.
Unit Tests:
The unit tests will form a separate executable, named unittest. It can be run without parameters to run all tests on the ReadingList class.
You can, however, list one or more test names as parameters to run those tests only. For example, if you are failing the testRLRemove test, run
./unittest testRLRemoveto focus on just that one test. This can be very useful when debugging your code, because the unit tests are simpler and will get to your Faculty code a great deal more directly than the full application.
You can also abbreviate test names to run all tests beginning with a string.
For example,
./unittest testRLRwould suffice to run that same single test.
Notes:
- You may use any of the techniques covered for manipulating data via iterators, including range-based loops, the auto keyword, and generic functions from the next lesson, if you are reading ahead.
- In designing the iterators for the ReadingList class, consider carefully the options of creating an new iterator class versus reusing an existing iterator type.
- The ReadingList class keeps its Books in order. Allowing application code to alter or reassign the internal sections via an iterator, e.g.,
· ReadingList::iterator it = myReadingList.begin();
· *it = Book(“99999”, “Zzarg, Jonathan”, “The Last Book Ever Written”);
would risk breaking that ordering, making any code that relies on the ordering fail.
That means that ReadingList needs to be one of those classes that use a single const iterator type as both iterator and const_iterator.
- You may find it a much more efficient use of your time to focus on passing the unit tests first and worry about system testing the full mergeLists application afterwards.
