Corning Community College
CSCS2320 Data Structures
Onto Stacks! Another very commonly used data structure, we will be building it atop our list.
Don't forget to contribute to project documentation! That helps to ensure everyone is invested in the project.
Our stack will in many ways be a restricted-access list: access with the stack functions will only manipulate the list at certain points, creating a consistency we don't have with full-access lists.
Stacks are a First In, First Out structure (or Last In, Last Out), and understanding the value that provides is key to effectively leveraging this data structure.
To assist with consistency across all implementations, project files for use with this project, along with the integration of the work you did on the last project, is made possible via a special recipe in the Makefile.
Simply go into the project base directory, and run:
lab46:~/src/SEMESTER/DESIG/prevPROJECT$ make upgrade-dls0
You will want to go here to edit and fill in the various sections of the document:
Stacks are linear data structures, that may be structured by linked lists. Linked lists are only accessed by one end and in the case of our project, this may be the lead or last node, (we will have to verify that with the unit tests scripts).
In the dls0/inc directory is a new file, stack.h , which defines the stack struct. The members of the stack struct for this project include Node *top (a pointer to the top of the stack), List *data (pointer to stack data), ulli size (size of the stack).
cd
The top of the stack follows the list in reverse order. The top of the stack will be equal to the last node of the list.
myStack → top = myList → last
There will be approximately 7 functions, will have to confirm that once you upgrade. These new functions go as follows:
Do your best to not reinvent the wheel. This project contains a lot of work with node's and list's and thoughtful use of previously made functions relating to those data structures will lead to cleaner code. This is also a time to test your previously made functions in an actual use environment, where you can see if it actually works outside of specified unit tests.
Below are pairings of stack functions on the left, and list functions that could be very useful in accomplishing these stack functions on the right.
mk.c → mklist
push.c → append
pop.c → obtain
cpstack.c → mkstack, cplist
peek.c → cpnode
rmstack.c → rmlist
KEY NOTE: Remember that the dereferenced version of the double pointers inside other functions you use should be NULL. Most of the functions previously made should have had an error if the dereferenced list/node was not NULL.
*Our task is to ask questions on Discord or in class and document our findings on this wiki page collaboratively, regarding the functionality of this project.
*For anybody interested in editing the wiki page, here is the dokuwiki user guide: https://www.dokuwiki.org/wiki:syntax#basic_text_formatting -Ash
Inside the stack are 3 different objects, a node, a list, and the size of the stack. The node is the top of the stack, and follows the last node of the list. For the purpose of your push and pop functions, new nodes from push should go to the end of the list, and that should be the new top. For pop, it should take off the end of the list, and reassign the new top, which is the last node in the list. Also, you can make use of the make command -make use-test-reference. This uses a working implementation of object files from the previous dllX projects, and can very much help you if your previous projects did not pass all unit tests.
No output should be visible outside of testing purposes inside unit tests. Functions will modify the corresponding list/node/stack according to what is asked of the function.
To be successful in this project, the following criteria (or their equivalent) must be met:
Let's say you have completed work on the project, and are ready to submit, you would do the following:
lab46:~/src/SEMESTER/DESIG/PROJECT$ make submit
You should get some sort of confirmation indicating successful submission if all went according to plan. If not, check for typos and or locational mismatches.
I'll be evaluating the project based on the following criteria:
91:dls0:final tally of results (91/91) *:dls0:obtained project by the Sunday prior to duedate [6/6] *:dls0:clean compile, no compiler messages [13/13] *:dls0:implementation passes unit tests [13/13] *:dls0:adequate modifications to code from template [26/26] *:dls0:program operations conform to project specifications [26/26] *:dls0:code tracked in lab46 semester repo [7/7]