C Programming - Lecture 7

1. C Programming - Lecture 7 • In this lecture we learn about: • Linked Lists • Binary Trees • How to test your code • What happens if you don’t

2. Structs which contain themselves • Sometimes programmers want structs in C to contain themselves. • For example, we might design an electronic dictionary which has a struct for each word and we might want to refer to synonyms which are also word structures. word1:run synonym1 synonym2 word3: jog synonym1 synonym2 word2: sprint synonym1 synonym2

3. How structs can contain themselves • Clearly a struct cannot literally contain itself. • But it can contain a pointer to the same type of struct struct silly_struct { /* This doesn't work */ struct silly_struct s1; }; struct good_struct { /* This does work */ struct *good_struct s2; };

4. The linked list - a common use of structs which contain themselves • Imagine we are reading lines from a file but don't know how many lines will be read. • We need a structure which can extend itself. This is known as a linked list. By passing the value of the head of the list to a function we can pass ALL the information.

5. head of list NULL How to set up a linked list typedef struct list_item { information in each item struct list_item *nextptr; } LIST_ITEM; This structure (where information is what you want each "node" of your linked list to contain). It is important that the nextptr of the last bit of the list contains NULL so that you know when to stop.

6. Address book with linked lists typedef struct list { char name[MAXLEN]; char address[MAXLEN]; char phone[MAXLEN]; struct list *next; } ADDRESS; ADDRESS *hol= NULL; /* Set the head of the list */

7. head of list NULL Linked list concepts Adding an item to the middle of the list head of list NULL move this link new item points at next item Deleting an item from the middle of the list move this link head of list NULL delete this node

8. Adding to our address book void add_to_list (void) /* Add a new name to our address book */ { ADDRESS *new_name; new_name= (ADDRESS *)malloc (sizeof (ADDRESS)); /* CHECK THE MEMORY! */ printf ("Name> "); fgets (new_name->name, MAXLEN, stdin); printf ("Address> "); fgets (new_name->address, MAXLEN, stdin); printf ("Tel> "); fgets (new_name->phone, MAXLEN, stdin); /* Chain the new item into the list */ new_name->next= hol; hol= new_name; }

9. The Binary Tree • A binary tree is a method for storing ordered data (for example a dictionary of words) where we wish to easily be able to add items and find items • Each element in the tree can lead to two further elements – to the left and to the right, representing elements which are earlier in the alphabet and later in the alphabet respectively

10. The binary tree NULL NULL typedef struct tree { char word[100]; struct tree *left; struct tree *right; } TREE; NULL NULL NULL NULL NULL

11. Binary Tree Pros & Cons • Finding an element is O(log n) • Adding an element is O(log n) – O(1) if we already know where to add it. • Deleting an element may be complex • Programming complexity is higher than a linked list (just about)

12. Deleting an entire binary tree • I think this code is elegant and worth looking at: void delete_tree (TREE *ptr) { if (ptr == NULL) return; delete_tree(ptr->left); delete_tree(ptr->right); free (ptr); } We can delete the whole tree with: delete_tree(root_of_tree);

13. Testing your code really works • Just because a piece of code works once doesn't mean it will work again. • Because we get a right answer for an input of 'n' does not mean we will get the right answer for 'm'. • Working code should never "crash" it should always exit with an error whatever its input. • You should know how your code will behave when asked "the wrong question".

14. Test boundary conditions • Consider what might happen if the input is very large or very small. • If there is a possibility that your code will get such input you should make sure it can deal with it. • Always beware of the divide by zero error. • In 1998 the guided-missile carrier USS Yorktown was shut down for several hours when a crew-member mistakenly input zero to one of the computers. Don't let your code work like this.

15. Boundary conditions example • What is wrong with this code which is supposed to be like strlen int my_strlen (char *string) /* What is wrong with this code to find the length of a string */ { int len= 1; while (string[len] != '\0') len++; return len; }

16. Overflows of numbers • If you are going to work with large numbers then be sure you know how large a number your variables can deal with. • In most implementations of C an unsigned char can be from 0 to 255. How big an int can be varies from computer to computer. • In July 1996 Ariane 5 exploded as a direct result of a programming error which tried to fit 64 bits of floating point into a 16 bit int.

17. What if the user asks "the wrong question" • This code finds the average of 'n' doubles - under what conditions does it fail. double avg (double a[], int n) /* a is an array of n doubles */ { int i; double sum= 0; for (i= 0; i < n; i++) { sum+= a[i]; } return sum/n; }

18. Program defensively • In some cases (not all) you might add code to weed out rogue values. void class_of_degree (char degree[], double percent) /* Work out the approx. class of degree from someone's percentage overall mark */ { if (percent < 0 || percent > 100) strcpy(degree,"Error in mark"); else if (percent >= 70) strcpy(degree,"First"); else if (percent >= 60) strcpy(degree,"Two-one"); . . } These lines are just here out of caution

19. How to test your code while writing • A good programmer doesn't sit down, write 10,000 lines of code and then run it. • It will make your life easier if you test your program as you write it. • Write the smallest possible part of the program you think will _do something_ and test it. • Build the program up gradually - testing as you go. • I like to compile every dozen lines or so – as soon as I've made a significant change. (I use a separate window to compile in).

20. When and what to test • If your program takes no input but simply runs and produces an answer then it may not need much testing. Most programs are not like this. • If you are doing the cryptography project or Zipf's law projects, for example, your programs should be taking strings of input. • What would happen if those strings of input were just rubbish instead of well behaved strings of words and letters.

21. Document your testing • Documenting your testing is critical and it will be important in your project. • If appropriate, you should include in your write up, some evidence that you have tested your code with various inputs • Failing to document testing can have important consequences • One of the problems which beset the Pathfinder probe had actually been spotted in testing before launch - but forgotten about. It had to be solved while in flight.