Differences

This shows you the differences between two versions of the page.

--- notes:data:fall2022:projects:sll4 [2022/10/18 11:37] – copied fixes from sll3 bolsen1
+++ notes:data:fall2022:projects:sll4 [2022/10/19 23:18] (current) – [BACKGROUND] dmuck
@@ Line 24: / Line 24: @@
 Once you upgrade to SLL4, you will now have a new file within the ''inc/'' directory called ''group.h''.
 Group is a new struct of data that will hold and link lists together. Just like you have a list of nodes, you will now have a group of lists, or a list of lists if you may.
+In group struct:
+    List *initial;                        // pointer to first list
+    List *closing;                        // pointer to last list
 Group has eight new list-group-processing functions, that are in charge of manipulating lists within our data structure. Going up one level of abstraction, lists are the new nodes! At this level, we are not worrying about manipulating nodes anymore, but only the node containers; in other words, we are only focusing on the addresses/pointers that hold lists, no more node processing this time.
+Take care to check the unit-test files for other functions that are being called in the event that you have not yet implemented them.
 =====SPECIFICATIONS=====
@@ Line 31: / Line 40: @@
   * mkgroup
   * rmgroup
-  * linsert
+  * Linsert
-  * lappend
+  * Lappend
-  * lobtain
+  * Lobtain
-  * ldisplay
+  * Ldisplay
-  * lgetpos
+  * Lgetpos
-  * lsetpos
+  * Lsetpos
@@ Line 43: / Line 52: @@
 *For anybody interested in editing the wiki page, here is the dokuwiki user guide: https://www.dokuwiki.org/wiki:syntax#basic_text_formatting -Ash
 =====PROGRAM=====
-Functions should be similar if not identical to the previous functions located in /src/list/. As for a recommended way to complete these. When display is not finished, it will output "NOT YET IMPLEMENTED".
+Functions should be similar if not identical to the previous functions located in /src/list/. As for a recommended way to complete these. It is highly recommended to reference (or even copy and modify if possible) your previous functions. This will drastically decrease your time spent on the project. When display is not finished, it will output "NOT YET IMPLEMENTED".
+For //Ldisplay()// the return value on success should be the number of lists printed. If the //pos// variable is 0 or greater, then it should always return 1 since only 1 list is being displayed. If //pos// is equal to -1, then it should return the total amount of lists in the group, or total displayed.
 =====OUTPUT SPECIFICATIONS=====
 Output should conform to the output of the unit tests, anything other than what is displayed inside the unit test is optional. If you are outputting anything other than the unit test, it would be a good idea to make sure it's fine instead of losing points trying to guess whether or not it is fine.
@@ Line 49: / Line 60: @@
 //ldisplay()//'s behavior indicates that //"on an error state, output "<ERROR>", return -2"//, the error state in this case would be an invalid position.
 =====UNIT TESTS=====
-Unit tests will rely upon one another as input/output/modifications to the list. A good majority of the functions call on display, so if you haven't completed display while checking it might lead to some issues. Make sure if you are getting issues that it isn't the unit test calling upon a not yet implemented function. Your display function will print **NOT YET IMPLEMENTED** if it isn't finished yet.
+Unit tests will rely upon one another as input/output/modifications to the list. A good majority of the functions call on display, so if you haven't completed display while checking it might lead to some issues. Make sure if you are getting issues that it isn't the unit test calling upon a not yet implemented function. Your display function will print **NOT YET IMPLEMENTED** if it isn't finished yet. Also, for some functions such as append, you might want to first do getpos/setpos, that way it will be easier to implement.
+An errors file will be created after running make, this may be helpful if things aren't compiling correctly.
+=====DEBUGGING=====
+Useful tools for debugging issues are gdb and examining the test files themselves. to utilize gdb, run the test program with the gdb command (not make check), with a command that might look like "gdb ./bin/unit-lobtain". Once in gdb the "run" command with start the program, and "break (line number)" will cause the program to stop at the specified line number. Once you have hit the breakpoint you can use "display (variable name)" to see the value of a variable at every step, "n" to step to the next line, and "continue" to continue running the program until the next breakpoint. Note that if you encounter a seg fault the program will tell the where the seg fault occurs, and you can use "run" again to restart the program.

Lab46 Wiki

User Tools

Site Tools

Differences

Page Tools