Project: Stack Variations

Preparation

Copy the source files to your own working directory, perhaps as follows.

cd ~/csc161/projects
cp -i -R /home/weinman/courses/CSC161/2021F/modules/pointers-stacks-queues/src/stacks ./

Part A: Code Analysis

Examine each of the four implementation approaches in the accompanying reading. For each approach, identify:

• what information is stored by a push (e.g., a copy of a string, a pointer to the original string, a pointer to a copy of the string)
• what information is returned by a pop (e.g., a pointer from the stack, a pointer to a string stored on the stack, a pointer to a copy of the string designated on the stack)

In each case, briefly justify your conclusions based on the code.

Part B: Experimentation

The program stack-project.c creates a single stack myStack and then uses the standard stack operations in the following sequence:

• initializes three strings with variables a, b, c
• pushes a, b, and c onto the stack
• pops the stack three times to get strings stored as variables d, e, and f
• prints the strings referenced by a, b, c, d, e, f
• changes strings a and e to a text not previously used (use strcpy from the string library)
• prints the strings referenced by a, b, c, d, e, f
• defines two new strings g and h, initialized to previously unused values
• pushes g and h onto the stack
• changes string g to a new value (use strcpy or access a specific character with a subscript—str[2] = 'q')
• prints the strings referenced by a, b, c, d, e, f, g, h

Review the output obtained with each of the four stack implementation approaches. Explain the results obtained (e.g., what variables remain the same, what changes and how/why).

Part C: Functional Stacks

The reading on stacks compared two stack interfaces: one that relies entirely on pointers and one that does not. You will explore the implications of this distinction in this part of the project.

1. First we must adapt one of the stack implementations so that it does not pass a pointer when the stack is unchanged. To do so, we will construct an entirely new and complete stack interface and implementation as follows. In all your work, be sure to carefully document the provenance of the source code.
   • Copy stack.h to a file called stack-func.h and change the declarations of all functions except initialize, push and pop to take simply a struct string_stack as a parameter, rather than a pointer.
   • Copy the declarations and definition from stack-buffer.h (sans the include guard) to your stack-func.h header.
   • Copy stack.c to a file called stack-func.c and change the implementations of the functions there to reflect the declarations from stack-func.h.
   • Copy the implementations from stack-2.c to your stack-func.c library and update the implementations to match the declarations of your stack-func.h header.
   • Add an entry to the Makefile to compile the object file stack-func.o. (Note that it is not yet linked to an executable.)
2. Next we will want to examine quantitatively the performance ramifications of these changes to the interface.
   • Copy program stack-project-compare.c. Inspect, compile (see the Makefile), and run the program to be sure you understand what it does.
   • The small stacks and strings are not likely to yield any insights. Change MAX_STACK_SIZE to 1024 and MAX_STRING_LENGTH to 1024 by providing these definitions during compilation:

     make clean
     make stack-project-compare CPPFLAGS="-DMAX_STRING_LENGTH=1024 -DMAX_STACK_SIZE=1024"

   • Use the Bash shell's time command to determine how long it takes to run the program with the original interface. For example,

     time ./stack-project-compare

     real    0m0.036s
     user    0m0.018s
     sys     0m0.015s

     To dissipate disk or network effects, you will likely want to run the command a few times until the numbers are approximately consistent. Make note of the user time, which indicates the amount of time the operating system spent running your code or library code (e.g., strcpy), rather than waiting for other programs or running priviledged instructions.
   • Now copy stack-project-compare.c to stack-project-compare-func.c, update it to include your stack-func.h, and change the necessary stack function calls to use the alternative interface, rather than pointers.

   • Update your Makefile with a new target named stack-project-compare-func that compiles the updated stack-project-compare-func.c and links it with stack-func.o. (Important: Make sure you clean the old object file first so it gets rebuilt with the larger string length and stack size definitions!)

     The resulting executable should be called stack-project-compare-func.

   • Compile the program and time how long it takes to run the program with the functional interface. To dissipate disk or network effects, you will likely want to run the command a few times until the numbers are approximately consistent. Make a note of the new user time.
   • To help you gain some perspective, add the following lines to the end of main in stack-project-compare.c

       /* compare argument sizes */
       printf("Stack argument size:         %ld\n", sizeof(*pStack));
       printf("Stack pointer argument size: %ld\n", sizeof(struct stack *));

3. What differences in performance do you notice between the original pointer-based and your updated, more functional stack interface? In particular, what is the ratio of the user times? Explain the likely cause of these differences.

Grading

Files to Submit

Following the general project submission guidelines, you should submit the following:

• stack-func.c and stack-func.h
• Makefile
• Modified stack-project-compare.c
• Commentary file (tests.txt)
  • Answers to questions as laid out below.
  • Transcript including compile and test run with data from stack-func.c with MAX_STACK_SIZE=MAX_STRING_LENGTH=1024.

In particular, no separate testing beyond C.1 and C.2 is necessary.

Rubric

In addition to the general grading guidelines for evaluation, the project is worth 24 points.

• [8 points] (Part A) Discussion of the four stack implementations
• [8 points] (Part B) Discussion of experimental output
• [8 points] (Part C) Functional stack implementation and comparison
  • [4 points] (C.1) Implements functional stack elements
  • [2 point] (C.3) Reports comparative performance times
  • [2 points] (C.3) Explains comparative performance times

A five point penalty will apply to any submission that includes personally identifying information anywhere other than the references/honesty file.