This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
notes:data:fall2022:projects:sll2 [2022/09/29 19:00] – Added fixes section documenting the problems and solutions I had trying to build the project after upgrading it bolsen1 | notes:data:fall2022:projects:sll2 [2022/10/05 18:05] (current) – [Basic GDB] gsuber | ||
---|---|---|---|
Line 10: | Line 10: | ||
</ | </ | ||
remove the following line of code (after the line that says '' | remove the following line of code (after the line that says '' | ||
- | <code> | + | <cli> |
- | @date +' | + | @date +' |
- | </code> | + | </cli> |
Then try building the project again. | Then try building the project again. | ||
=====BACKGROUND===== | =====BACKGROUND===== | ||
+ | In previous weeks we have been building our list library to include some tools to check our lists for various things. This week we will add functionality modify its contents with a bit more precision. Ever thought you might want to clear the contents and/or remove your list entirely; once you are done with it, of course... Maybe you want to sort your list by the values its nodes contain or simply remove a node and move some things around yourself? If so, cool. Make it do the thing. | ||
| | ||
+ | This week we will finish up the core functions by adding obtain to our list library. | ||
+ | The three core functions are insert, append, and obtain. | ||
+ | |||
+ | This week you will find five new '' | ||
We have 5 tasks to do for full credit. These are: | We have 5 tasks to do for full credit. These are: | ||
- | * clear() | + | * clear() |
- | * obtain() | + | * obtain() contains a double pointer (should use getpos() and setpos() from previous sllX) |
- | * rm() | + | * rm() should be making use of the clear() |
- | * sort() | + | * sort() |
- | * swap() | + | * swap() |
- | You also have an extra task, for extra credit, inside app/list/ of your sll2 base directory. The extra credit task is to build a linked list based on input from the user. You will also determine whether or not this linked list is a palindrome linked list or not. In case you don't know what a palindrome list is, here is an example. A palindrome list is a list that would look the same if you reversed it. For example, if you have a list, 1 2 3 2 1, that would be a palindrome, because if you display it backwards or forwards, it would display the same thing. | + | You also have an extra task, for extra credit |
+ | |||
+ | The palindrome should accept values either from the CLI, stdin, or both. Be able to determine if the created list is a palindrome. Reverse the list(hint: use sortlist()). Finally, display the list. | ||
*Our task is to ask questions on Discord or in class and document our findings on this wiki page collaboratively, | *Our task is to ask questions on Discord or in class and document our findings on this wiki page collaboratively, | ||
Line 34: | Line 40: | ||
=====PROGRAM===== | =====PROGRAM===== | ||
Recommended Order to make functions: | Recommended Order to make functions: | ||
- | 1. Obtain()\\ | + | - obtain() |
- | 2. clearlist()\\ | + | |
- | 3. rmlist()\\ | + | |
- | 4. swap()\\ | + | |
- | 5. sort()\\ | + | |
Details as to the behaviour of the functions can be found as comments inside the .c files of the programs themselves, located in src/list. If confusion arises in the make check process to verify then the .c code of the verify files can be found inside the unit/list directory. Do note that the verify code can rely upon some of the functions you are making to check the others, hence the recommended order. | Details as to the behaviour of the functions can be found as comments inside the .c files of the programs themselves, located in src/list. If confusion arises in the make check process to verify then the .c code of the verify files can be found inside the unit/list directory. Do note that the verify code can rely upon some of the functions you are making to check the others, hence the recommended order. | ||
+ | |||
+ | The unit tests for sll2 make use of several of the functions made in previous projects as well. So if some of those other functions aren’t working as they should be, it could cause mismatches in the unit tests for sll2. It may be helpful to run the unit tests individually to check the output of specific functions. | ||
+ | |||
+ | Make sure to not overestimate what you are trying to do, especially in obtain(), do not try to optimize your program by removing the node, because the node will be held in the double pointer thatNode. | ||
+ | |||
+ | If you have difficulty debugging **obtain()**, | ||
=====OUTPUT SPECIFICATIONS===== | =====OUTPUT SPECIFICATIONS===== | ||
=====UNIT TESTS===== | =====UNIT TESTS===== | ||
+ | =====Basic GDB===== | ||
+ | GDB is a very useful tool, especially if you are running into segmentation faults on any unit test. GDB allows you to set breakpoints, | ||
+ | |||
+ | To launch gdb (obtain used as example): | ||
+ | <cli> | ||
+ | USER@lab46: | ||
+ | </ | ||
+ | |||
+ | ===Basic Operations=== | ||
+ | |||
+ | Placing a breakpoint at line #5: | ||
+ | <cli> | ||
+ | (gdb) b 5 | ||
+ | </ | ||
+ | |||
+ | Placing a breakpoint at function //main()//: | ||
+ | <cli> | ||
+ | (gdb) b main | ||
+ | </ | ||
+ | |||
+ | Run program until next breakpoint: | ||
+ | <cli> | ||
+ | (gdb) r | ||
+ | **or** | ||
+ | (gdb) run | ||
+ | </ | ||
+ | |||
+ | Continue after breakpoint is hit: | ||
+ | <cli> | ||
+ | (gdb) c | ||
+ | </ | ||
+ | |||
+ | Display variable state: | ||
+ | <cli> | ||
+ | (gdb) print var | ||
+ | </ | ||
+ | |||
+ | Execute one line (after breakpoint is hit): | ||
+ | <cli> | ||
+ | (gdb) n | ||
+ | </ | ||
+ | |||
+ | Step into function: | ||
+ | <cli> | ||
+ | (gdb) s | ||
+ | </ |