Author: Chris Wyatt
| Assigned: | 10/16 |
| Due: | 10/31 by 11:55 pm (Wyatt section) |
| Starter Code: | P3.zip |
This assignment is split into two parts. The goal of the first part is to implement and test two ordered list implementations. In part two you will use these implementations to implement a simple todo tracking application inspired by todo.txt.
In this part you will define, implement and test two approaches to ordered lists. The file abstract_list.hpp in the stater code defines the templated interface, AbstractList, for an ordered list. You should define two templates DynamicArrayList and LinkedList that publicly inherit from the interface in the appropriate header file (dynamic_array_list.hpp and linked_list.hpp respectively). These templates should override the following methods from the interface (see abstract_list.hpp for details) and provide a constructor, copy constructor, copy-assignment operator, and destructor.
Note: the AbstractList interface uses 0-based indexing.
DynamicArrayList should use a dynamically allocated array to hold its data, with initially allocted size of zero and growing in size by powers of two as needed. LinkedList should use a singly-linked list to hold its data, in both case as private members. The template method implementations should be placed in the files dynamic_array_list.tpp and linked_list.tpp respectively and be included in their respective headers.
Define tests for both your list implementations in the file test_list.cpp, which uses Catch as in previous assignments. The tests should be the same for both lists with only the list type used varying between them.
You are a busy person. You need a way to track your tasks (todo's). In this part you will gain experience with lists by writing a program to help you do this called todo. You should use your implementation of either the array or linked list classes from part I.
todo is a text-mode (command-line) application that manages a plain text file holding your tasks. It allows you to do three basic things: add a task with a task description; list tasks, and mark tasks as done. These operations are specified as command-line arguments to the executable which reads, processes, and potentially changes the todo storage file on each program invocation. The main entry point should be in the file main.cpp with any classes or free functions you write to implement the application functionality in the module todo.hpp/todo.cpp. The starter code is setup to build the application this way. See entry 3 in the FAQ for information on command-line parameters if you are not familiar with them.
The basic usage is as follows (assuming windows executable):
todo.exe [-f file] command The -f flag says which file to use for storage. If not present, this defaults to the file todo.txt in the current directory. In either case if the specified file does not exist it is considered a user error. You can use any plain text format for storage file you like, but keep it simple. I would recommend using a character delimited file format with an escape sequence for the delimiting character.
command can be one of:
add - add a task to the file, all remaining text is considered the task descriptionlist - print a list of all tasks to standard output line-by-line in the format below using 1-based indexing, if any text remains after this command it is an error. Completed tasks should be listed lastdo - marks the task on the specified line as done. Doing a task twice does nothing. Only one item can be marked done at a time. Attempting to mark a nonexistant line is an error.Output format for list command:
lineno:[x] task descriptionwhere lineno is replaced with the current item number starting at one, and the x is printed inside the brackets for tasks marked completed and a space for those not.
Examples: Your application should produce the same output. Note % below is juat a placeholder for whatever your command prompt is.
List all tasks stored in the default file.
% todo.exe listList all tasks in the file last_semester.txt.
% todo.exe -f last_semester.txt listAdd some tasks, then list them, then make one as done, then list again.
% todo.exe add start HW 0
% todo.exe add "read first chapter for class"
% todo.exe add "ask about templates during office hours"
% todo.exe list
1:[ ] start HW 0
2:[ ] read first chapter for class
3:[ ] ask about templates during office hours
% todo.exe do 2
% todo.exe list
1:[ ] start HW 0
2:[ ] ask about templates during office hours
3:[x] read first chapter for classNote in the last example, marking task 2 as done rotates it to the end of the list and shifts the remaining tasks to one lower position (in the example "ask about ..." moves from position 3 to position 2)
On success your program should return EXIT_SUCCESS but print no extraneous output other than than specified. On a user or application error your program should print an informative error message to standard error, that begins with the string "Error", and return EXIT_FAILURE. The constants EXIT_SUCCESS and EXIT_FAILURE are defined in the header cstdlib.
You can use the grader to check your list tests and to test your list implementations against my tests by uploading the files: dynamic_array_list.hpp, dynamic_array_list.tpp, linked_list.hpp, linked_list.tpp, and test_list.cpp. There is a build target called "submission" configured by default to create this file with the correct contents in your build directory.
The CMakeLists.txt in the starter code is setup to run your list tests from part I as well as a few simple tests for the todo application in part II. You should perform additional manual or automatic testing to be sure your todo application follows the specification above.
Once you are satisfied your code satisfies the project specification, upload the zip file containing your submission, through Canvas at the assignment link). The list of files to include is: dynamic_array_list.hpp, dynamic_array_list.tpp, linked_list.hpp, linked_list.tpp, test_list.cpp, main.cpp, todo.hpp, todo.cpp.
You should not submit the other files from the starter code, nor your build directory.
There are 60 points allocated to Part I.
There are 40 points allocated to Part II.
The Part II correctness and design portions of the grade will be assessed by the TA using the following criteria:
std::vector or std::list)