This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
haas:fall2015:data:projects:dll1 [2015/06/27 20:39] – external edit 127.0.0.1 | haas:fall2015:data:projects:dll1 [2015/11/02 10:41] (current) – [List library unit tests] wedge | ||
---|---|---|---|
Line 30: | Line 30: | ||
As such, new function prototypes have been added to the list.h header file: | As such, new function prototypes have been added to the list.h header file: | ||
- | < | + | < |
- | code_t | + | code_t |
- | code_t | + | code_t |
+ | code_t | ||
- | code_t | + | code_t |
- | code_t | + | |
- | code_t | + | code_t |
- | code_t | + | code_t |
</ | </ | ||
These functions will also make use of the status/ | These functions will also make use of the status/ | ||
+ | |||
+ | The recommended order of implementation is: | ||
+ | |||
+ | - **obtain()** | ||
+ | - **empty()** | ||
+ | - **rmlist()** | ||
+ | - **compare()** | ||
+ | - **swapnode()** | ||
+ | - **sortlist()** (although note that sorting doesn' | ||
+ | |||
+ | Implementing them out of order will likely result in unnecessary duplication of efforts, and I really don't want to see a half dozen half-baked **obtain()** implementations dribbled throughout your code. | ||
====list operation status codes==== | ====list operation status codes==== | ||
- | You'll notice the presence of a set of # | + | Just as with dll0, you'll notice the presence of a set of # |
They are not exclusive- in some cases, multiple states can be applied. The intent is that you will OR together all pertinent states and return that from the function. | They are not exclusive- in some cases, multiple states can be applied. The intent is that you will OR together all pertinent states and return that from the function. | ||
Line 63: | Line 74: | ||
ALL THREE states must be returned from the function in question should such an occurrence take place. | ALL THREE states must be returned from the function in question should such an occurrence take place. | ||
+ | |||
+ | ===compare status codes=== | ||
+ | dll1 introduces additional status codes for one of its functions: **compare()** | ||
+ | |||
+ | Those codes are as follows: | ||
+ | |||
+ | <code c> | ||
+ | ////////////////////////////////////////////////////////////////////// | ||
+ | // | ||
+ | // Status codes for the doubly-linked list compare() function | ||
+ | // | ||
+ | # | ||
+ | # | ||
+ | # | ||
+ | # | ||
+ | # | ||
+ | # | ||
+ | # | ||
+ | # | ||
+ | # | ||
+ | </ | ||
====list library==== | ====list library==== | ||
In **src/ | In **src/ | ||
Line 71: | Line 103: | ||
====List library unit tests==== | ====List library unit tests==== | ||
- | In **testing/list/unit/**, you will find these new files: | + | In **unit/list/**, 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-obtain.c** - unit test for **obtain()** library function | ||
- | * **unit-compare.c** - unit test for **compare()** library function | ||
* **unit-empty.c** - unit test for **empty()** library function | * **unit-empty.c** - unit test for **empty()** library function | ||
- | * **unit-sort.c** - unit test for **sort()** library function | + | * **unit-rmlist.c** - unit test for **rmlist()** library function |
- | * **unit-swap.c** - unit test for **swap()** library function | + | * **unit-compare.c** - unit test for **compare()** library function |
+ | * **unit-swap.c** - unit test for **swapnode()** library function | ||
+ | * **unit-sort.c** - unit test for **sortlist()** library function | ||
Enhancements to these unit tests may be provided via dll1 project updates. | Enhancements to these unit tests may be provided via dll1 project updates. | ||
Line 98: | Line 130: | ||
* ask questions to get clarification! | * ask questions to get clarification! | ||
+ | Also note that, while considerable effort was made to ensure a broad range of tests were incorporated into each unit test, they are by no means a complete nor exhaustive battery of tests. There may be scenarios the unit tests do not currently check for. You are welcome and encouraged to perform additional tests to ensure your implementation is as rock solid as it can be. | ||
+ | |||
+ | ====List library applications==== | ||
+ | |||
+ | ===palindrome=== | ||
+ | Now that we've completed our doubly-linked list functionality, | ||
+ | |||
+ | Our endeavor here will be to revisit that of palindromes (ie words/ | ||
+ | |||
+ | This implementation will be considered an extra credit opportunity, | ||
+ | |||
+ | It is also highly recommended to undertake as it will give you further experience working with these concepts. | ||
=====Expected Results===== | =====Expected Results===== | ||
To assist you in verifying a correct implementation, | To assist you in verifying a correct implementation, | ||
Line 106: | Line 150: | ||
<cli> | <cli> | ||
- | lab46: | + | lab46: |
- | ==================================================== | + | ====================================================== |
- | = Verifying Doubly-Linked List Functionality | + | = Verifying Doubly-Linked |
- | ==================================================== | + | ====================================================== |
- | [mklist] Total: | + | [obtain] Total: |
- | [cplist] Total: | + | |
- | [append] Total: | + | [rmlist] Total: |
- | | + | [compare] Total: |
- | [display] Total: | + | [swapnode] Total: |
- | | + | [sortlist] Total: |
- | [compare] Total: | + | ====================================================== |
- | | + | |
- | [rmlist] Total: | + | ====================================================== |
- | [obtain] Total: | + | |
- | [swap] Total: | + | |
- | [sort] Total: | + | |
- | ==================================================== | + | |
- | | + | |
- | ==================================================== | + | |
lab46: | lab46: | ||
</ | </ | ||
- | =====Submission | + | =====Submission===== |
- | To be successful in this project, the following criteria must be met: | + | {{page> |
- | * Project must be submit on time, by the posted deadline. | ||
- | * Late submissions will lose 25% credit per day, with the submission window closing on the 4th day following the deadline. | ||
- | * All code must compile cleanly (no warnings or errors) | ||
- | * all requested functions must be implemented in the related library | ||
- | * all requested functionality must conform to stated requirements (either on this project page or in comment banner in source code files themselves). | ||
- | * Executed programs must display in a manner similar to provided output | ||
- | * output formatted, where applicable, must match that of project requirements | ||
- | * Processing must be correct based on input given and output requested | ||
- | * Output must be correct (i.e. the list visualization, | ||
- | * Code must be nicely and consistently indented (you may use the **indent** tool) | ||
- | * Code must be commented | ||
- | * Any "to be implemented" | ||
- | * these "to be implemented" | ||
- | * Sufficient comments explaining the point of provided logic **MUST** be present | ||
- | * Track/ | ||
- | * Submit a copy of your source code to me using the **submit** tool (**make submit** will do this) by the deadline. |