Lab 3 - History


Directions

  • Submit your completed lab online to CourSys (not Canvas, not GitHub).
    • Labs are marked on completion, not correctness, so complete each part to the best of your ability and learn.
    • Lab is due Sunday and may be submitted up to 3 days late. Further extensions possible only in exceptional cases.
  • It is recommended that students attend in-person lab sections for lots of support!
    • You are invited to come to any (or more than one) lab section.
    • There is no need to attend the section you are enrolled in.
    • There is no need to attend any lab sections: there is no attendance taken.
    • You can complete the lab on your own time or own computer if you like.
    • Time suggestions are given here to guide students who are working on the lab during lab times. However, the entire lab must be completed by everyone for marks.
  • While completing these labs, you are encouraged to help your classmates and receive as much help as you like. Assignments, however, are individual work and you must not work with another person on assignments.
    • I recommend coming to the lab and working with someone.
    • Failing that, I recommend getting together with someone in the class outside of lab time to work through the lab together.
    • Failing that, you are welcome to complete the lab exercise without any collaboration.
    • Each student must submit their lab to get marks.
    • Academic honesty expectations for labs are that each student types their own lab solution. It is OK to share ideas and help each others with specific coding issues and design. It is not permitted to submit another student's file for credit.
  • If using CSIL lab PC:
    • [Only CSIL PC] If in Windows, reboot to Linux; while booting, select Ubuntu from boot menu.
    • [Only CSIL PC] Don't setup GitHub tokens in the cmpt201 container because it may be shared with other users.
    • [Only CSIL PC] Delete any possible previous docker container before starting the lab:
      docker rm cmpt201
    • [Only CSIL PC] When done your lab, copy your solution out of the container, then execute the above docker command to delete your docker container to leave it clean for the next user.
  • You do not need to use record.


Prerequisite Skills for This Lab

  • Able to read characters in from keyboard one line at a time.
  • C Skills
    • Able to create and use arrays.
    • Able to pass arrays to functions.
    • Able to manage pointers and data in an array.
    • Able to free dynamically allocated memory.
    • Able to compile, run, and debug C programs.


Your task is...

In a file name lab3.c, write a program that does the following:

  • Read in user input​ from the keyboard line by line; each input can include spaces or other characters.
  • Stores the last 5 lines of user inputs.
  • When the user enters the command print (no arguments), then print the last 5 lines of user input to the screen.
    • print would then be the most recent user input, and be shown as such in the output below.

Example output

Enter input: Hello world!
Enter input: yes
Enter input: print
Hello world!
yes
print
Enter input: And this is
Enter input: Just another input
Enter input: line
Enter input: here
Enter input: print
And this is
Just another input
line
here
print
Enter input:
Enter input: that was blank!
Enter input: see it!
Enter input: print
print

that was blank!
see it!
print
Enter input: ^C

(Ended with Ctrl+c)


1. Design (10 mins)

Design your solution.

  • Plan your solution using pseudocode.
  • Start by identifying what data your program need to store.
    • Hint - Data structure: What data structure would be best for storing 5 things of the same data type? Don't use 5 individual variables!
    • Hint - Pointer vs String: Input from the user will be a dynamically allocated string (from getline()). Would it be easier to have the history store a pointer for each user input, or to copy each input into pre-allocated strings (null-terminated arrays of characters)? Is there a maximum length for a user input?
    • Hint - Local vs Global: Will your data be stored in local or global variables? When in doubt, try making everything local and passing it between functions.
  • Use functions to break out non-trivial operations such as managing the input history.
    • Hint - Readability: Try to make main() read like a book: don't put complex code in main(), move it into well named functions.
  • How are you handling dynamically allocated memory?
    • Remember that getline() can allocate space for the strings. When do you free any dynamically allocated memory?
  • Discuss with your partner, or someone else, how your design will work.
  • Try not to Google it; you need these skills. Labs are for figuring it out, not for coping.


2. Implement it! (25 mins)

  • Write a couple lines of code then compile, run, debug. Repeat!
  • Do simplest thing first (read input and output it?). Then add functionality bit-by-bit.
  • Help others around you!


3. Reviewing (15 mins)

  • During the last 15 minutes of the in-person lab, TAs will show a sample solution.
  • TAs will talk through how the solution works and discuss its implementation.
  • Discussion Points
    • How does it actually work?
      • What syscalls / library functions does it use? How do those work? Use man page as needed.
    • How does it handle errors?
    • How could the design and/or code be improved? Look at data storage, functions, etc.
  • Now that you have seen the solution:
    • Finish implementing your solution: don't just copy the solution, but it is OK if you use the ideas you saw to help you finish.
    • Revise your solution to improve it based on what you learned.


4. [Optional] Challenges

  1. Optional: Refactor (cleanup) your code to improve its readability.
    • Review your main() function and look for ways to make it clearer.
    • Consider if any of your code could be made into functions that are easier to understand or call.
    • Consider how you are storing data. Can you think of any ways to make the code clearer?
    • Review another student's solution:
      • Suggest one or two thing you like about their code.
      • Suggest one or two things they could improve in their code.
      • Note: It is fine to show your lab code to another student, and it is OK for them to use ideas they learned from your code and your feedback.
    • Change your code using these ideas.
  2. Optional: Change your program to ignore blank lines of user input.
    • When the user enters a blank line, don't add it to the history.
  3. Optional: Add a clear command that will erase the current history.


Submission

Submit your C code to CourSys by Sunday midnight. The file name must be an exact match to what CourSys is expecting, otherwise it won't accept it. Remember you can submit up to 3 days late with no penalty if needed (but please plan to get it done on time to stay up to date on the course!)

Submissions will be marked for completion. It must be valid C code that runs (however we are unlikely to actually compile and run the code). You do not need to complete any optional steps.