- 作业标题：CSCI 2122 - Systems Programming - lab4 Pointers, Memory Allocation, Structs
- 课程名称：Dalhouse University CSCI 2122 Systems Programming
- 完成周期：1天
1. Introduction
This lab is designed to introduce you to command line arguments, reading and writing files, the wonderful world of memory management, and structures. By the end of this lab, you will be expected to understand the following:
- Reading arguments from the command line.
- Pointers.
- File I/O.
- Memory management.
- Type definitions (typedef).
- Structures (struct).
The proceeding labs will build and expand this knowledge into the realm of low level computing, including memory management, data structures, methods for approaching low-level computation, and a variety of other subjects. As such, knowing these key principles will be important for future programming and development. In this lab you are expected to perform the basics of cloning your Lab 4 repository from the GitLab course group.
A link to the course group can be found here and your repository can be found in the Lab4 subgroup. See the Lab Technical Document for more information on using git. You will notice that your repository has a file in the Lab4 directory named delete this file. Due to the limitations of GitLab, we are not able to push completely empty directories. Before your push your work to your repository (which should be in the Lab4 directory anyway), make sure to first use the git rm command to remove the extra file. If you do not, your pipeline will fail.
2. Pointers
In C, the only way to transfer data between functions is to pass a copy of the desired values, which happens automatically. For example, if you want to take an integer value and push it into a function via the function arguments, C will allocate a new memory block for that integer, initialize it to the same value as the value being passed, then provide the function with the newly allocated variable instead of this original. The same thing occurs when you assign a variable holding a primitive data type to a new variable of the same type. Consider the following example:
1 int a = 13;
2 int b = a;
3 b = b + 5;
4 int c = a + b;
After that code is executed, what is the c variable’s value? Common C logic would dictate that c = 13 + 13 + 5 = 31, but if C did not create copies of primitive values, something different would happen: a = 13, then b = a, but because we aren’t creating copies, b becomes a by being assigned a’s memory location. This means that both b and a are now using the same place in memory to store their value, so anything that happens to a will also happen to b. Next, b = b + 5, which means b = 18, but since a also uses b’s memory location, a = 18 now as well. When c = a + b, let’s assume the arithmetic add produces a brand new value (because if it didn’t, this would really be a brutal pain to deal with), and since a is b, this means c = 18+18 = 36, a far cry different from our normal expectations. As such, it’s important that C (and basically every other language) adheres to some form of pass-by-copy in order to function properly. However, there will be times when it’s beneficial to not pass-by-copy in the traditional sense, but instead pass a copy of a piece of data’s memory address. Having the ability to do this introduces several benefits:
- We are able to pass large blocks of data between functions without wasting time copying that data in its entirety.
- We can work directly on a single piece of data by using a variety of functions, rather than one long function.
- We can control the way data is conceptualized by the system by manipulating the way C is viewing that data.
At its most basic level, a pointer is a variable that holds a memory address. Every time a variable is created, a space in memory is held by the system which is equal to the size of the variable’s data type. For a regular variable, it’s possible to access that memory location by using the & operator, also known as the address-of operator. You may have noticed that it is necessary to use the & operator when scanning input. This is to ensure that we don’t make a new copy of a variable’s memory space, and instead completely replace the value in the variable’s memory space. If you have access to a variable’s memory address, you are able to alter the contents of that variable in-place, circumventing the normal pass-by-copy rules:
。。。
3. Lab 4 Function Contracts
In this lab you will be responsible for fulfilling two lab contracts: the book contract and the calculator contract. Each contract is designed to test you on some of the things you’ve learned throughout the instruction portion of this lab.
All contracts must be completed exactly as the requirements are laid out. Be very careful to thoroughly read the contract instructions before proceeding. This does not, however, preclude you from writing more functions than you are asked for. You may write as many additional functions as you wish in your C source files. All contracts are designed to be submitted without a main function, but that does not mean you cannot write a main function in order to test your code yourself. It may be more convenient for you to write a C source file with a main function by itself and take advantage of the compiler’s ability to link files together by accepting multiple source files as inputs. When you push your code to Gitlab, you don’t need to git add any of your extra main function source files.
The programs you write for this lab will not be compiled with any additional libraries, as they should not be required. For those of you who are concerned, when deciding which naming conventions you want to use in your code, favour consistency in style, not dedication to a style that doesn’t work. The contracts in this document are worth the following points values, for a total of 10.
。。。
4. Submission
4.1. Required Files
When submitting this lab, you must submit your C source and header files only. Each file must be contained in the directory listed in the structure requirement diagram below. These files include:
- book.c
- book.h
- calculator.c
- calculator.h
As with all labs, submitting anything other than what is required in this section will yield a mark of 0.
4.2. Submission Procedure and Expectations
Your code will be submitted to your Lab 4 GitLab repository using the same method as outlined in the Lab Technical Document. Refer to that document if you do not remember how to submit files via the GitLab service. A link to your repository can be found in the Lab4 subgroup of the CSCI 2122 GitLab group here.
As mentioned in the Lab Technical Document, we will provide you with a CI/CD script file which will help you test your submissions. The .yml file containing the CI/CD test script logic, and any other necessary script files, are available in your repository at all times. You are free to view any of the script files to help you understand how our marking scripts will function. We make extensive use of relative path structures for testing purposes, which is why strict adherence to directory structure and file contents is such a necessity. Also remember to check your pipeline job outputs on the GitLab web interface for your repository to see where your jobs might be failing.
Remember to follow the instruction guidelines as exactly as possible. Sometimes the pipeline scripts will not test every detail of your submission. Do not rely on us to perfectly test your code before submission. The
CI/CD pipeline is a great tool for helping you debug major parts of your submissions, but you are still expected to follow all rules as they have been laid out.
。。。
