Corning Community College
CSCS2320 Data Structures
~~TOC~~
======Project: SLL1======
=====Errata=====
This section will document any updates applied to the project since original release:
* __revision 1__: I discovered a typo in the unit tests for swapnode and rmlist, the for loop iterators were going the wrong way. FIXED. (20141016)
=====Objective=====
We've commenced on our list explorations, implementing some of the core functionality (adding nodes to a list through insertion or appending) as well as some helper functionality to make our list transactions even more effective (displaying, getting node positions, setting node positions).
In this project, we continue our list implementation by exploring the removal of nodes from a list, searching for nodes within a list, clearing a list, and swapping two nodes within an existing list.
=====Project Overview=====
====header file====
In **src/inc/** is the list header file: **list.h**
For this project, we're going to be implementing the following functions:
Node *searchlist(List *, int); // locate node containing value
List *obtain (List *, Node ** ); // obtain/disconnect node from list
List *rmlist(List *); // remove all nodes from list
List *swapnode(List *, Node *, Node *); // swap positions of given nodes in list
As a suggestion, I'd recommend implementing them in the order listed above, starting with **searchlist()** and then **obtain()**. By doing this, you get to review a bit from the previous weeks (**searchlist()**) and then continue with base functionality (**obtain()**), which will help you in your implementation of the other functions.
An important perspective to keep when implementing these list functions is to be mindful of what functionality can be a unit of something else. Do not reinvent the wheel- utilize functions you've written- it will shorten your code, and reduce the chance of error. Plus, that IS the intent.. to have each function be specific and focused on its particular task; to do one thing, and do that one thing extremely well. We can then use them as base units to build more sophisticated functionality.
In this project, **searchlist()** and **obtain()** are those basic operations, where **rmlist()** and **swapnode()** can be build using various functions you'll be writing in this project and in previous projects.
====list library====
In **src/list/**, you will find 4 new C files:
* **obtain.c** - which will house the list obtain function (to disconnect nodes from a list)
* **rm.c** - which will handle clearing the list
* **search.c** - which will house the list search function
* **swap.c** - which will handle swapping two nodes within a list
Take a look at the code there. These are the files that contain functions which will be compiled and archived into the node library (**liblist.a**) we will be using in this and future projects.
Figure out what is going on, make sure you understand it.
**NOTE:** None of these files denote an entire runnable program. These are merely standalone functions. The various programs under the **testing/** directory will use these functions in addition to their application logic to create complete executable programs.
You will also notice there are function prototypes for these list library functions in the **list.h** header file, located in the **inc/** subdirectory, which you'll notice all the related programs you'll be playing with in this project are **#include**ing.
====List library unit tests====
In **testing/list/unit/**, you will find these new files:
* **unit-rmlist.c** - unit test for **rmlist()** library function
* **unit-obtain.c** - unit test for **obtain()** library function
* **unit-searchlist.c** - unit test for **searchlist()** library function
* **unit-swapnode.c** - unit test for **swapnode()** library function
These are complete runnable programs (when compiled, and linked against the list library, which is all handled for you by the **Makefile** system in place).
Of particular importance, I want you to take a close look at:
* the source code to each of these unit tests
* the purpose of these programs is to validate the correct functionality of the respective library functions
* follow the logic
* make sure you understand what is going on
* ask questions to get clarification!
* the output from these programs once compiled and ran
* analyze the output
* make sure you understand what is going on
* ask questions to get clarification!
=====Submission Criteria=====
To be successful in this project, the following criteria must be met:
* Code must compile cleanly (no warnings or errors)
* all requested functions must be implemented in the related library
* Executed programs must display in a manner similar to provided output
* Processing must be correct based on input given and output requested
* Output must be correct (i.e. the list visualization, where applicable) based on values input
* Code must be nicely and consistently indented (you may use the **indent** tool)
* Code must be commented
* Track/version the source code in a repository
* Submit a copy of your source code to me using the **submit** tool (**make submit** will do this) by the deadline.