CS202 Review Session 1 Notes from [Xiangyu Gao](https://xiangyug.github.io/), TA from fall 2021 Edited by Khanh Nguyen, TA Spring 2022 1. Introduction 2. Logistics 3. Motivation & tips for success 4. Compilation process & Makefile 5. Git introduction 6. Lab Overview & C review 7. Debugging -------------------------------------------------- 1. Introduction 2. Logistics - 5 review sessions in total, 1 hour each. - help you go through the labs overview and highlight the important background knowledge. - Ask me any questions. If I can't answer them, please post on Campuswire (CW). - PLEASE don't ask me if you code is correct. Lab is an opportunity for you to learn and you should test your code. 3. Motivation & tips for success - Personally, I find the material very useful in the day to day job in the industry. You will hear terms: processes, threads and memory thrown around in technical docs as well as codebase. So I think the course prepares the foundation significantly. To succeed in cs202: - Start on time. Read through the code and lab write up before coding. Understand the overall design first. - PUT IN THE WORK. I don't mean only doing the lab. It means keeping up with the reading, reviewing notes, handouts, doing the homeworks and labs. - DON'T CHEAT. - Exam is one of the many data points. Don't get discouraged if you don't do too hot on the midterm. Pull your weight and be consistent throughout the course 4. Compilation & Makefile - [See diagram in the whiteboard or in lecture's notes] - Makefile: - a special file, containing shell commands, that you create and name it "Makefile". When you type in the terminal: "make", the command will find the Makefile and executes the appropriate shell command. - Why use a Makefile? a. Easy to maintain. Don't mix up commands and repeatedly find them b. More effecient. Compile files that change. - E.g: [See whiteboard] 5. Git introduction - Git is an open source distributed version control system, created by Linus, who also wrote Linux. - Distributed Version Control System: - It means that Git has multiple places toestore code. It has a remote repository stored in a server and a local repository. Each developer will develop code in their own machine and upload the changes - There are usually conflicts when it comes to merging your changes and others' changes. Sometimes, it can be merged directly. But sometimes, you need to resolve the conflicts manually. These issue have 2nd level priority in our class so we won't discuss them in details here. - Git != GitHub. - GitHub is a hosting website that stores git repositories. Other service is GitLab. Git is the software that keeps track your changes. ** I recommend learning to interact with the terminal. Don't rely too much on the GUI. At the basics, you should know UNIX commands: ls, pwd, cd, cat, ..** 6. Lab Overview - Lab 1 is easier than other labs. So don't get ahead of yourself if you finish the lab early. If you are unsure about your C skills, I recommend looking at K&R: The C programming language. - Remember to set up the virtual machine. All your labs will be graded on the same environment. If you have M1 Macbook, see the setup for cims. a. Declaration & initialization /* * * Declaration. Dereferencing x will lead to undefined behavior. * Remember to initialize your variables. */ int * x; b. Pointer (variable) - Pointers in C are fun to learn! (Controversial I know). Some C programming tasks are performed more easily with pointers, and other tasks, such as dynamic memory allocation, which cannot be performed without using pointers. - Definition: An address within memory OR a variable whose value is the address of another variable. - Format: type * variable_name. - '*' denotes the pointer type. Don't confuse this with accessing/dereferencing pointers. - '*' can also be used to access contents. E.g1: char * name = "Alice"; // pointer to string Alice printf("%c\n", *name); // 'A'. *name is equivalent to accessing the 1st char E.g2: See the whiteboards for others. Fun exercise: Try copy the code into your machine. Before running it, read through the code and think what would happen. Then run it to double check your understanding. Change it around and redo the process. c. Mental Model - Everyone has different mental model when it comes to pointers. I will present my way of thinking about pointers. - I like to think about variable or code as boxes. So pointer, to me, is a box that contains memory address: E.g: int a = 1; int* b = &a; int** c = &b; - In my brain, with the example, this is what's going on: a [ 1 ] 0x100 b [ 0x100 ] 0x108 c [ 0x108 ] 0x116 - So as you see, b refers to the memory address that store a's value. c refers to address of b. And if there's a dereferencing, you just follow the trail of address. int* x = *c; // x will refers to b's value so x [ 0x100 ] int y = *x // y will be 1. Try work this out and understand it on paper. Why? - Save lots of space since 1 pointer is 8 bytes (on x86-64). - Achieve more functionalities when writing subfunctions. - Analogy: + Buying a Tesla model X. It will cost 100K. + You can give the seller 100K stack in cash OR + You can write a check with address to a bank account with 100K balance. The seller will prefer if you choose the 2nd option. It will be a lot easier to process. d. Array and string - There is no built-in type string in C :O - 2 ways to access element in array: subscript and pointer arithmetic. - Character array is terminated with a null byte, indicating the end of the string. E.g: // will compile sometimes but this is not correct char name[5] = "Alice"; // correct way to initialize string with length 5. Need 1 more for null byte char name[6] = "Alice"; /* * * "Alice" is a string constant in read-only region. Write/modify can lead to * undefined behavior. */ char * name = "Alice"; 7. Debugging - Don't try changing your code around without thinking about it first. It will waste lots of your time and not cost effective. More importantly, sometimes, you won't even know why your code fails and how you ACTUALLY fix it. - Some bugs are hard to find. Be familiar with gdb, which is a debugger tool. Lab 1 will have exercise for you to practice. - Can also use printf or combination of printf + gdb. But printf is also not the greatest strategy. If you notice you rely on using printf too much, try switching to gdb. - Don't be scared of compiler warnings and errors. Compiler, most of the times, is your friend.