Free Essay

C++ Linkedlist Problems

In:

Submitted By taruo
Words 7907
Pages 32
Linked List Problems
By Nick Parlante
Copyright ©1998-2002, Nick Parlante

Abstract This document reviews basic linked list code techniques and then works through 18 linked list problems covering a wide range of difficulty. Most obviously, these problems are a way to learn about linked lists. More importantly, these problems are a way to develop your ability with complex pointer algorithms. Even though modern languages and tools have made linked lists pretty unimportant for day-to-day programming, the skills for complex pointer algorithms are very important, and linked lists are an excellent way to develop those skills. The problems use the C language syntax, so they require a basic understanding of C and its pointer syntax. The emphasis is on the important concepts of pointer manipulation and linked list algorithms rather than the features of the C language. For some of the problems we present multiple solutions, such as iteration vs. recursion, dummy node vs. local reference. The specific problems are, in rough order of difficulty: Count, GetNth, DeleteList, Pop, InsertNth, SortedInsert, InsertSort, Append, FrontBackSplit, RemoveDuplicates, MoveNode, AlternatingSplit, ShuffleMerge, SortedMerge, SortedIntersect, Reverse, and RecursiveReverse. Contents Section 1 — Review of basic linked list code techniques Section 2 — 18 list problems in increasing order of difficulty Section 3 — Solutions to all the problems 3 10 20

This is document #105, Linked List Problems, in the Stanford CS Education Library. This and other free educational materials are available at http://cslibrary.stanford.edu/. This document is free to be used, reproduced, or sold so long as this notice is clearly reproduced at its beginning. Related CS Education Library Documents Related Stanford CS Education library documents... • Linked List Basics (http://cslibrary.stanford.edu/103/) Explains all the basic issues and techniques for building linked lists. • Pointers and Memory (http://cslibrary.stanford.edu/102/) Explains how pointers and memory work in C and other languages. Starts with the very basics, and extends through advanced topics such as reference parameters and heap management. • Binary Trees (http://cslibrary.stanford.edu/110/) Introduction to binary trees • Essential C (http://cslibrary.stanford.edu/101/) Explains the basic features of the C programming language.

2 • The Great Tree List Problem (http://cslibrary.stanford.edu/109/) Presents the greatest recursive pointer problem ever devised. Why Linked Lists Are Great To Study Linked lists hold a special place in the hearts of many programmers. Linked lists are great to study because... • Nice Domain The linked list structure itself is simple. Many linked list operations such as "reverse a list" or "delete a list" are easy to describe and understand since they build on the simple purpose and structure of the linked list itself. • Complex Algorithm Even though linked lists are simple, the algorithms that operate on them can be as complex and beautiful as you want (See problem #18). It's easy to find linked list algorithms that are complex, and pointer intensive. • Pointer Intensive Linked list problems are really about pointers. The linked list structure itself is obviously pointer intensive. Furthermore, linked list algorithms often break and re-weave the pointers in a linked list as they go. Linked lists really test your understanding of pointers. • Visualization Visualization is an important skill in programming and design. Ideally, a programmer can visualize the state of memory to help think through the solution. Even the most abstract languages such as Java and Perl have layered, reference based data structures that require visualization. Linked lists have a natural visual structure for practicing this sort of thinking. It's easy to draw the state of a linked list and use that drawing to think through the code. Not to appeal to your mercenary side, but for all of the above reasons, linked list problems are often used as interview and exam questions. They are short to state, and have complex, pointer intensive solutions. No one really cares if you can build linked lists, but they do want to see if you have programming agility for complex algorithms and pointer manipulation. Linked lists are the perfect source of such problems. How To Use This Document Try not to use these problems passively. Take some time to try to solveeach problem. Even if you do not succeed, you will think through the right issues in the attempt, and looking at the given solution will make more sense. Use drawings to think about the problems and work through the solutions. Linked lists are well-suited for memory drawings, so these problems are an excellent opportunity to develop your visualization skill. The problems in this document use regular linked lists, without simplifcations like dummy headers. Dedication This Jan-2002 revision includes many small edits. The first major release was Jan 17, 1999. Thanks to Negar Shamma for her many corrections. This document is distributed for the benefit and education of all. Thanks to the support of Eric Roberts and Stanford University. That someone seeking education should have the opportunity to find it. May you learn from it in the spirit of goodwill in which it is given. Best Regards, Nick Parlante -- nick.parlante@cs.stanford.edu

3

Section 1 — Linked List Review
This section is a quick review of the concepts used in these linked list problems. For more detailed coverage, see Link List Basics (http://cslibrary.stanford.edu/103/) where all of this material is explained in much more detail. Linked List Ground Rules All of the linked list code in this document uses the "classic" singly linked list structure: A single head pointer points to the first node in the list. Each node contains a single .next pointer to the next node. The .next pointer of the last node is NULL. The empty list is represented by a NULL head pointer. All of the nodes are allocated in the heap. For a few of the problems, the solutions present the temporary "dummy node" variation (see below), but most of the code deals with linked lists in their plain form. In the text, brackets {} are used to describe lists — the list containing the numbers 1, 2, and 3 is written as {1, 2, 3}. The node type used is... struct node { int data; struct node* next; };

To keep thing ssimple, we will not introduce any intermediate typedefs. All pointers to nodes are declared simply as struct node*. Pointers to pointers to nodes are declared as struct node**. Such pointers to pointers are often called "reference pointers". Basic Utility Functions In a few places, the text assumes the existence of the following basic utility functions... • int Length(struct node* head); Returns the number of nodes in the list. • struct node* BuildOneTwoThree(); Allocates and returns the list {1, 2, 3}. Used by some of the example code to build lists to work on. • void Push(struct node** headRef, int newData); Given an int and a reference to the head pointer (i.e. a struct node** pointer to the head pointer), add a new node at the head of the list with the standard 3-step-link-in: create the new node, set its .next to point to the current head, and finally change the head to point to the new node. (If you are not sure of how this function works, the first few problems may be helpful warm-ups.)

4 Use of the Basic Utility Functions This sample code demonstrates the basic utility functions being used. Their implementations are also given in the appendix at the end of the document. void BasicsCaller() { struct node* head; int len; head = BuildOneTwoThree(); // Start with {1, 2, 3} Push(&head, 13); // Push 13 on the front, yielding {13, 1, 2, 3} // (The '&' is because head is passed // as a reference pointer.) // // // // // Push 42 into the second position yielding {13, 42, 1, 2, 3} Demonstrates a use of '&' on the .next field of a node. (See technique #2 below.)

Push(&(head->next), 42);

len = Length(head); }

// Computes that the length is 5.

If these basic functions do not make sense to you, you can (a) go see Linked List Basics (http://cslibrary.stanford.edu/103/) which explains the basics of linked lists in detail, or (b) do the first few problems, but avoid the intermediate and advanced ones.

Linked List Code Techniques
The following list presents the most common techniques you may want to use in solving the linked list problems. The first few are basic. The last few are only necessary for the more advanced problems. 1. Iterate Down a List A very frequent technique in linked list code is to iterate a pointer over all the nodes in a list. Traditionally, this is written as a while loop. The head pointer is copied into a local variable current which then iterates down the list. Test for the end of the list with current!=NULL. Advance the pointer with current=current->next.
// Return the number of nodes in a list (while-loop version) int Length(struct node* head) { int count = 0; struct node* current = head; while (current != NULL) { count++; current = current->next; } return(count); }

Alternately, some people prefer to write the loop as a for which makes the initialization, test, and pointer advance more centralized, and so harder to omit... for (current = head; current != NULL; current = current->next) {

5 2. Changing a Pointer Using a Reference Pointer Many list functions need to change the caller's head pointer. In C++, you can just declare the pointer parameter as an & argument, and the compiler takes care of the details. To do this in the C language, pass a pointer to the head pointer. Such a pointer to a pointer is sometimes called a "reference pointer". The main steps for this technique are... • Design the function to take a pointer to the head pointer. This is the standard technique in C — pass a pointer to the "value of interest" that needs to be changed. To change a struct node*, pass a struct node**. • Use '&' in the caller to compute and pass a pointer to the value of interest. • Use '*' on the parameter in the callee function to access and change the value of interest. The following simple function sets a head pointer to NULL by using a reference parameter....
// Change the passed in head pointer to be NULL // Uses a reference pointer to access the caller's memory void ChangeToNull(struct node** headRef) { // Takes a pointer to // the value of interest *headRef = NULL; } // use '*' to access the value of interest

void ChangeCaller() { struct node* head1; struct node* head2; ChangeToNull(&head1); // use '&' to compute and pass a pointer to ChangeToNull(&head2); // the value of interest // head1 and head2 are NULL at this point }

Here is a drawing showing how the headRef pointer in ChangeToNull() points back to the variable in the caller...

Stack
ChangeCaller() head1

ChangeToNull(&head1) headRef

6 Many of the functions in this document use reference pointer parameters. See the use of Push() above and its implementation in the appendix for another example of reference pointers. See problem #8 and its solution for a complete example with drawings. For more detailed explanations, see the resources listed on page 1. 3. Build — At Head With Push() The easiest way to build up a list is by adding nodes at its "head end" with Push(). The code is short and it runs fast — lists naturally support operations at their head end. The disadvantage is that the elements will appear in the list in the reverse order that they are added. If you don't care about order, then the head end is the best. struct node* AddAtHead() { struct node* head = NULL; int i; for (i=1; inext. The only "problem" with this solution is that writing separate special case code for the first node is a little unsatisfying. Nonetheless, this approach is a solid one for production code — it is simple and runs fast. struct node* BuildWithSpecialCase() { struct node* head = NULL; struct node* tail; int i; // Deal with the head node here, and set the tail pointer Push(&head, 1); tail = head; // Do all the other nodes using 'tail' for (i=2; inext), i); // add node at tail->next tail = tail->next; // advance tail to point to last node } return(head); } // head == {1, 2, 3, 4, 5};

6. Build — Temporary Dummy Node This is a slightly unusual technique that can be used to shorten the code: Use a temporary dummy node at the head of the list during the computation. The trick is that with the dummy, every node appears to be added after the .next field of some other node. That way the code for the first node is the same as for the other nodes. The tail pointer plays the same role as in the previous example. The difference is that now it also handles the first node as well. struct node* BuildWithDummyNode() { struct node dummy; // Dummy node is temporarily the first node struct node* tail = &dummy; // Start the tail at the dummy. // Build the list on dummy.next (aka tail->next) int i; dummy.next = NULL; for (i=1; inext), i); tail = tail->next; } // The real result list is now in dummy.next // dummy.next == {1, 2, 3, 4, 5}; return(dummy.next); }

8 Some linked list implementations keep the dummy node as a permanent part of the list. For this "permanent dummy" strategy, the empty list is not represented by a NULL pointer. Instead, every list has a heap allocated dummy node at its head. Algorithms skip over the dummy node for all operations. That way the dummy node is always present to provide the above sort of convenience in the code. I prefer the temporary strategy shown here, but it is a little peculiar since the temporary dummy node is allocated in the stack, while all the other nodes are allocated in the heap. For production code, I do not use either type of dummy node. The code should just cope with the head node boundary cases. 7. Build — Local References Finally, here is a tricky way to unify all the node cases without using a dummy node at all. For this technique, we use a local "reference pointer" which always points to the last pointer in the list instead of to the last node. All additions to the list are made by following the reference pointer. The reference pointer starts off pointing to the head pointer. Later, it points to the .next field inside the last node in the list. (A detailed explanation follows.) struct node* BuildWithLocalRef() { struct node* head = NULL; struct node** lastPtrRef= &head; // Start out pointing to the head pointer int i; for (i=1; inext); // Advance to point to the // new last pointer } // head == {1, 2, 3, 4, 5}; return(head); }

This technique is short, but the inside of the loop is scary. This technique is rarely used, but it's a good way to see if you really understand pointers. Here's how it works... 1) At the top of the loop, lastPtrRef points to the last pointer in the list. Initially it points to the head pointer itself. Later it points to the .next field inside the last node in the list. 2) Push(lastPtrRef, i); adds a new node at the last pointer. The new node becomes the last node in the list. 3) lastPtrRef= &((*lastPtrRef)->next); Advance the lastPtrRef to now point to the .next field inside the new last node — that .next field is now the last pointer in the list. Here is a drawing showing the state of memory for the above code just before the third node is added. The previous values of lastPtrRef are shown in gray...

9

Stack
LocalRef() head

Heap

1

2

lastPtrRef

This technique is never required to solve a linked list problem, but it will be one of the alternative solutions presented for some of the advanced problems. The code is shorter this way, but the performance is probably not any better. Unusual Techniques Both the temporary-stack-dummy and the local-reference-pointer techniques are a little unusual. They are cute, and they let us play around with yet another variantion in pointer intensive code. They use memory in unusual ways, so they are a nice way to see if you really understand what's going on. However, I probably would not use them in production code.

10

Section 2 — Linked List Problems
Here are 18 linked list problems arranged in order of difficulty. The first few are quite basic and the last few are quite advanced. Each problem starts with a basic definition of what needs to be accomplished. Many of the problems also include hints or drawings to get you started. The solutions to all the problems are in the next section. It's easy to just passively sweep your eyes over the solution — verifying its existence without lettings its details touch your brain. To get the most benefit from these problems, you need to make an effort to think them through. Whether or not you solve the problem, you will be thinking through the right issues, and the given solution will make more sense. Great programmers can visualize data structures to see how the code and memory will interact. Linked lists are well suited to that sort of visual thinking. Use these problems to develop your visualization skill. Make memory drawings to trace through the execution of code. Use drawings of the pre- and post-conditions of a problem to start thinking about a solution. "The will to win means nothing without the will to prepare." - Juma Ikangaa, marathoner (also attributed to Bobby Knight)

1 — Count()
Write a Count() function that counts the number of times a given int occurs in a list. The code for this has the classic list traversal structure as demonstrated in Length(). void CountTest() { List myList = BuildOneTwoThree(); int count = Count(myList, 2); } // build {1, 2, 3} // returns 1 since there's 1 '2' in the list

/* Given a list and an int, return the number of times that int occurs in the list. */ int Count(struct node* head, int searchFor) { // Your code

11

2 — GetNth()
Write a GetNth() function that takes a linked list and an integer index and returns the data value stored in the node at that index position. GetNth() uses the C numbering convention that the first node is index 0, the second is index 1, ... and so on. So for the list {42, 13, 666} GetNth() with index 1 should return 13. The index should be in the range [0..length1]. If it is not, GetNth() should assert() fail (or you could implement some other error case strategy). void GetNthTest() { struct node* myList = BuildOneTwoThree(); int lastNode = GetNth(myList, 2); } // build {1, 2, 3} // returns the value 3

Essentially, GetNth() is similar to an array[i] operation — the client can ask for elements by index number. However, GetNth() no a list is much slower than [ ] on an array. The advantage of the linked list is its much more flexible memory management — we can Push() at any time to add more elements and the memory is allocated as needed.
// Given a list and an index, return the data // in the nth node of the list. The nodes are numbered from 0. // Assert fails if the index is invalid (outside 0..lengh-1). int GetNth(struct node* head, int index) { // Your code

3 — DeleteList()
Write a function DeleteList() that takes a list, deallocates all of its memory and sets its head pointer to NULL (the empty list). void DeleteListTest() { struct node* myList = BuildOneTwoThree(); // build {1, 2, 3}

DeleteList(&myList); // deletes the three nodes and sets myList to NULL }

Post DeleteList() Memory Drawing The following drawing shows the state of memory after DeleteList() executes in the above sample. Overwritten pointers are shown in gray and deallocated heap memory has an 'X' through it. Essentially DeleteList() just needs to call free() once for each node and set the head pointer to NULL.

12

Stack
DeleteListTest() myList

Heap

myList is overwritten with the value NULL.

1

2

3

The three heap blocks are deallocated by calls to free(). Their memory will appear to be intact for a while, but the memory should not be accessed. DeleteList() The DeleteList() implementation will need to use a reference parameter just like Push() so that it can change the caller's memory (myList in the above sample). The implementation also needs to be careful not to access the .next field in each node after the node has been deallocated. void DeleteList(struct node** headRef) { // Your code

4 — Pop()
Write a Pop() function that is the inverse of Push(). Pop() takes a non-empty list, deletes the head node, and returns the head node's data. If all you ever used were Push() and Pop(), then our linked list would really look like a stack. However, we provide more general functions like GetNth() which what make our linked list more than just a stack. Pop() should assert() fail if there is not a node to pop. Here's some sample code which calls Pop().... void PopTest() { struct node* head = BuildOneTwoThree(); int a = Pop(&head); // deletes "1" node and int b = Pop(&head); // deletes "2" node and int c = Pop(&head); // deletes "3" node and int len = Length(head); // the list } // build {1, 2, 3} returns 1 returns 2 returns 3 is now empty, so len == 0

Pop() Unlink Pop() is a bit tricky. Pop() needs to unlink the front node from the list and deallocate it with a call to free(). Pop() needs to use a reference parameter like Push() so that it can change the caller's head pointer. A good first step to writing Pop() properly is making the memory drawing for what Pop() should do. Below is a drawing showing a Pop() of the first node of a list. The process is basically the reverse of the 3-Step-Link-In used by Push() (would that be "Ni Knil Pets-3"?). The overwritten pointer value is shown in gray, and the deallocated heap memory has a big 'X' drawn on it...

13

Stack
PopTest() head

Heap

The head pointer advances to refer to the node after the unlinked one.

1

2

3

The unlinked node is deallocated by a call to free(). Ironically, the unlinked node itself is not changed immediately. It is no longer appears in the list just because the head pointer no longer points to it. Pop()
/* The opposite of Push(). Takes a non-empty list and removes the front node, and returns the data which was in that node. */ int Pop(struct node** headRef) { // your code...

5 — InsertNth()
A more difficult problem is to write a function InsertNth() which can insert a new node at any index within a list. Push() is similar, but can only insert a node at the head end of the list (index 0). The caller may specify any index in the range [0..length], and the new node should be inserted so as to be at that index. void InsertNthTest() { struct node* head = NULL; InsertNth(&head, 0, 13); InsertNth(&head, 1, 42); InsertNth(&head, 1, 5); DeleteList(&head); } // start with the empty list // build {13) // build {13, 42} // build {13, 5, 42}

// clean up after ourselves

14 InsertNth() is complex — you will want to make some drawings to think about your solution and afterwards, to check its correctness.
/* A more general version of Push(). Given a list, an index 'n' in the range 0..length, and a data element, add a new node to the list so that it has the given index. */ void InsertNth(struct node** headRef, int index, int data) { // your code...

6 — SortedInsert()
Write a SortedInsert() function which given a list that is sorted in increasing order, and a single node, inserts the node into the correct sorted position in the list. While Push() allocates a new node to add to the list, SortedInsert() takes an existing node, and just rearranges pointers to insert it into the list. There are many possible solutions to this problem. void SortedInsert(struct node** headRef, struct node* newNode) { // Your code...

7 — InsertSort()
Write an InsertSort() function which given a list, rearranges its nodes so they are sorted in increasing order. It should use SortedInsert().
// Given a list, change it to be in sorted order (using SortedInsert()). void InsertSort(struct node** headRef) { // Your code

8 — Append()
Write an Append() function that takes two lists, 'a' and 'b', appends 'b' onto the end of 'a', and then sets 'b' to NULL (since it is now trailing off the end of 'a'). Here is a drawing of a sample call to Append(a, b) with the start state in gray and the end state in black. At the end of the call, the 'a' list is {1, 2, 3, 4}, and 'b' list is empty.

Stack

Heap

a b

1

2

3

4

15 It turns out that both of the head pointers passed to Append(a, b) need to be reference parameters since they both may need to be changed. The second 'b' parameter is always set to NULL. When is 'a' changed? That case occurs when the 'a' list starts out empty. In that case, the 'a' head must be changed from NULL to point to the 'b' list. Before the call 'b' is {3, 4}. After the call, 'a' is {3, 4}.

Stack

Heap

a b

3

4

// Append 'b' onto the end of 'a', and then set 'b' to NULL. void Append(struct node** aRef, struct node** bRef) { // Your code...

9 — FrontBackSplit()
Given a list, split it into two sublists — one for the front half, and one for the back half. If the number of elements is odd, the extra element should go in the front list. So FrontBackSplit() on the list {2, 3, 5, 7, 11} should yield the two lists {2, 3, 5} and {7, 11}. Getting this right for all the cases is harder than it looks. You should check your solution against a few cases (length = 2, length = 3, length=4) to make sure that the list gets split correctly near the short-list boundary conditions. If it works right for length=4, it probably works right for length=1000. You will probably need special case code to deal with the (length data == searchFor) count++; current = current->next; } return count; }

Alternately, the iteration may be coded with a for loop instead of a while... int Count2(struct node* head, int searchFor) { struct node* current; int count = 0; for (current = head; current != NULL; current = current->next) { if (current->data == searchFor) count++; } return count; }

2 — GetNth() Solution
Combine standard list iteration with the additional problem of counting over to find the right node. Off-by-one errors are common in this sort of code. Check it carefully against a simple case. If it's right for n=0, n=1, and n=2, it will probably be right for n=1000. int GetNth(struct node* head, int index) { struct node* current = head; int count = 0; // the index of the node we're currently looking at while (current != NULL) { if (count == index) return(current->data); count++; current = current->next; } assert(0); } // if we get to this line, the caller was asking // for a non-existent element so we assert fail.

21

3 — DeleteList() Solution
Delete the whole list and set the head pointer to NULL. There is a slight complication inside the loop, since we need extract the .next pointer before we delete the node, since after the delete it will be technically unavailable. void DeleteList(struct node** headRef) { struct node* current = *headRef; // deref headRef to get the real head struct node* next; while (current != NULL) { next = current->next; free(current); current = next; } *headRef = NULL; }

// note the next pointer // delete the node // advance to the next node

// Again, deref headRef to affect the real head back // in the caller.

4 — Pop() Solution
Extract the data from the head node, delete the node, advance the head pointer to point at the next node in line. Uses a reference parameter since it changes the head pointer. int Pop(struct node** headRef) { struct node* head; int result; head = *headRef; assert(head != NULL); result = head->data; // pull out the data before the node is deleted *headRef = head->next; // unlink the head node for the caller // Note the * -- uses a reference-pointer // just like Push() and DeleteList(). free(head); return(result); } // free the head node // don't forget to return the data from the link

5 — InsertNth() Solution
This code handles inserting at the very front as a special case. Otherwise, it works by running a current pointer to the node before where the new node should go. Uses a for loop to march the pointer forward. The exact bounds of the loop (the use of < vs next), data); // Tricky use of Push() -// The pointer being pushed on is not // in the stack. But actually this works // fine -- Push() works for any node pointer. } }

6 — SortedInsert() Solution
The basic strategy is to iterate down the list looking for the place to insert the new node. That could be the end of the list, or a point just before a node which is larger than the new node. The three solutions presented handle the "head end" case in different ways...
// Uses special case code for the head end void SortedInsert(struct node** headRef, struct node* newNode) { // Special case for the head end if (*headRef == NULL || (*headRef)->data >= newNode->data) { newNode->next = *headRef; *headRef = newNode; } else { // Locate the node before the point of insertion struct node* current = *headRef; while (current->next!=NULL && current->next->datadata) { current = current->next; } newNode->next = current->next; current->next = newNode; } }

// Dummy node strategy for the head end void SortedInsert2(struct node** headRef, struct node* newNode) { struct node dummy; struct node* current = &dummy; dummy.next = *headRef; while (current->next!=NULL && current->next->datadata) { current = current->next; } newNode->next = current->next; current->next = newNode;

23
*headRef = dummy.next; }

// Local references strategy for the head end void SortedInsert3(struct node** headRef, struct node* newNode) { struct node** currentRef = headRef; while (*currentRef!=NULL && (*currentRef)->datadata) { currentRef = &((*currentRef)->next); } newNode->next = *currentRef; *currentRef = newNode; } // Bug: this line used to have // an incorrect (*currRef)->next

7 — InsertSort() Solution
Start with an empty result list. Iterate through the source list and SortedInsert() each of its nodes into the result list. Be careful to note the .next field in each node before moving it into the result list.
// Given a list, change it to be in sorted order (using SortedInsert()). void InsertSort(struct node** headRef) { struct node* result = NULL; // build the answer here struct node* current = *headRef; // iterate over the original list struct node* next; while (current!=NULL) { next = current->next; // tricky - note the next pointer before we change it SortedInsert(&result, current); current = next; } *headRef = result; }

8 — Append() Solution
The case where the 'a' list is empty is a special case handled first — in that case the 'a' head pointer needs to be changed directly. Otherwise we iterate down the 'a' list until we find its last node with the test (current->next != NULL), and then tack on the 'b' list there. Finally, the original 'b' head is set to NULL. This code demonstrates extensive use of pointer reference parameters, and the common problem of needing to locate the last node in a list. (There is also a drawing of how Append() uses memory below.) void Append(struct node** aRef, struct node** bRef) { struct node* current; if (*aRef == NULL) { // Special case if a is empty *aRef = *bRef; } else { // Otherwise, find the end of a, and append b there current = *aRef; while (current->next != NULL) { // find the last node current = current->next; }

24 current->next = *bRef; } *bRef=NULL; } // NULL the original b, since it has been appended above // hang the b list off the last node

Append() Test and Drawing The following AppendTest() code calls Append() to join two lists. What does memory look like just before the call to Append() exits? void AppendTest() { struct node* a; struct node* b; // set a to {1, 2} // set b to {3, 4} Append(&a, &b); }

As an example of how reference parameters work, note how reference parameters in Append() point back to the head pointers in AppendTest()...

Stack
AppendTest() a b Append(&a, &b) aRef bRef current

Heap

1

2

3

4

9 — FrontBackSplit() Solution
Two solutions are presented...
// Uses the "count the nodes" strategy void FrontBackSplit(struct node* source, struct node** frontRef, struct node** backRef) { int len = Length(source); int i; struct node* current = source;

25

if (len < 2) { *frontRef = source; *backRef = NULL; } else { int hopCount = (len-1)/2; //(figured these with a few drawings) for (i = 0; inext; } // Now cut at current *frontRef = source; *backRef = current->next; current->next = NULL; } }

// Uses the fast/slow pointer strategy void FrontBackSplit2(struct node* source, struct node** frontRef, struct node** backRef) { struct node* fast; struct node* slow; if (source==NULL || source->next==NULL) { *frontRef = source; *backRef = NULL; } else { slow = source; fast = source->next; // length < 2 cases

// Advance 'fast' two nodes, and advance 'slow' one node while (fast != NULL) { fast = fast->next; if (fast != NULL) { slow = slow->next; fast = fast->next; } } // 'slow' is before the midpoint in the list, so split it in two // at that point. *frontRef = source; *backRef = slow->next; slow->next = NULL; } }

10 — RemoveDuplicates() Solution
Since the list is sorted, we can proceed down the list and compare adjacent nodes. When adjacent nodes are the same, remove the second one. There's a tricky case where the node after the next node needs to be noted before the deletion.
// Remove duplicates from a sorted list void RemoveDuplicates(struct node* head) { struct node* current = head;

26

if (current == NULL) return;

// do nothing if the list is empty

// Compare current node with next node while(current->next!=NULL) { if (current->data == current->next->data) { struct node* nextNext = current->next->next; free(current->next); current->next = nextNext; } else { current = current->next; // only advance if no deletion } } }

11 — MoveNode() Solution
The MoveNode() code is most similar to the code for Push(). It's short — just changing a couple pointers — but it's complex. Make a drawing. void MoveNode(struct node** destRef, struct node** sourceRef) { struct node* newNode = *sourceRef; // the front source node assert(newNode != NULL); *sourceRef = newNode->next; newNode->next = *destRef; *destRef = newNode; } // Advance the source pointer // Link the old dest off the new node // Move dest to point to the new node

12 — AlternatingSplit() Solution
The simplest approach iterates over the source list and use MoveNode() to pull nodes off the source and alternately put them on 'a' and b'. The only strange part is that the nodes will be in the reverse order that they occurred in the source list. AlternatingSplit() void AlternatingSplit(struct node* source, struct node** aRef, struct node** bRef) { struct node* a = NULL; // Split the nodes to these 'a' and 'b' lists struct node* b = NULL; struct node* current = source; while (current != NULL) { MoveNode(&a, ¤t); // Move a node to 'a' if (current != NULL) { MoveNode(&b, ¤t); // Move a node to 'b' } } *aRef = a; *bRef = b; }

27 AlternatingSplit() Using Dummy Nodes Here is an alternative approach which builds the sub-lists in the same order as the source list. The code uses a temporary dummy header nodes for the 'a' and 'b' lists as they are being built. Each sublist has a "tail" pointer which points to its current last node — that way new nodes can be appended to the end of each list easily. The dummy nodes give the tail pointers something to point to initially. The dummy nodes are efficient in this case because they are temporary and allocated in the stack. Alternately, the "local references" technique could be used to get rid of the dummy nodes (see Section 1 for more details). void AlternatingSplit2(struct node* source, struct node** aRef, struct node** bRef) { struct node aDummy; struct node* aTail = &aDummy; // points to the last node in 'a' struct node bDummy; struct node* bTail = &bDummy; // points to the last node in 'b' struct node* current = source; aDummy.next = NULL; bDummy.next = NULL; while (current != NULL) { MoveNode(&(aTail->next), ¤t); // add at 'a' tail aTail = aTail->next; // advance the 'a' tail if (current != NULL) { MoveNode(&(bTail->next), ¤t); bTail = bTail->next; } } *aRef = aDummy.next; *bRef = bDummy.next; }

13 SuffleMerge() Solution
There are four separate solutions included. See Section 1 for information on the various dummy node and reference techniques. SuffleMerge() — Dummy Node Not Using MoveNode() struct node* ShuffleMerge(struct node* a, struct node* b) { struct node dummy; struct node* tail = &dummy; dummy.next = NULL; while (1) { if (a==NULL) { tail->next = b; break; } else if (b==NULL) { tail->next = a; break; } else { tail->next = a; tail = a; a = a->next;

// empty list cases

// common case: move two nodes to tail

28 tail->next = b; tail = b; b = b->next; } } return(dummy.next); }

SuffleMerge() — Dummy Node Using MoveNode() Basically the same as above, but use MoveNode(). struct node* ShuffleMerge(struct node* a, struct node* b) { struct node dummy; struct node* tail = &dummy; dummy.next = NULL; while (1) { if (a==NULL) { tail->next = b; break; } else if (b==NULL) { tail->next = a; break; } else { MoveNode(&(tail->next), &a); tail = tail->next; MoveNode(&(tail->next), &b); tail = tail->next; } } return(dummy.next); }

SuffleMerge() — Local References Uses a local reference to get rid of the dummy nodes entirely. struct node* ShuffleMerge(struct node* a, struct node* b) { struct node* result = NULL; struct node** lastPtrRef = &result; while (1) { if (a==NULL) { *lastPtrRef = b; break; } else if (b==NULL) { *lastPtrRef = a; break; } else { MoveNode(lastPtrRef, &a); lastPtrRef = &((*lastPtrRef)->next); MoveNode(lastPtrRef, &b); lastPtrRef = &((*lastPtrRef)->next);

29
} } return(result); }

SuffleMerge() — Recursive The recursive solution is the most compact of all, but is probably not appropriate for production code since it uses stack space proportionate to the lengths of the lists. struct node* ShuffleMerge(struct node* a, struct node* b) { struct node* result; struct node* recur; if (a==NULL) return(b); // see if either list is empty else if (b==NULL) return(a); else { // it turns out to be convenient to do the recursive call first -// otherwise a->next and b->next need temporary storage. recur = ShuffleMerge(a->next, b->next); result = a; a->next = b; b->next = recur; return(result); } } // one node from a // one from b // then the rest

14 — SortedMerge() Solution
SortedMerge() Using Dummy Nodes The strategy here uses a temporary dummy node as the start of the result list. The pointer tail always points to the last node in the result list, so appending new nodes is easy. The dummy node gives tail something to point to initially when the result list is empty. This dummy node is efficient, since it is only temporary, and it is allocated in the stack. The loop proceeds, removing one node from either 'a' or 'b', and adding it to tail. When we are done, the result is in dummy.next. struct node* SortedMerge(struct node* a, struct node* b) { struct node dummy; // a dummy first node to hang the result on struct node* tail = &dummy; // Points to the last result node -// so tail->next is the place to add // new nodes to the result. dummy.next = NULL; while (1) { if (a == NULL) { // if either list runs out, use the other list tail->next = b; break; } else if (b == NULL) { tail->next = a; break; }

30 if (a->data data) { MoveNode(&(tail->next), &a); } else { MoveNode(&(tail->next), &b); } tail = tail->next; } return(dummy.next); }

SortedMerge() Using Local References This solution is structurally very similar to the above, but it avoids using a dummy node. Instead, it maintains a struct node** pointer, lastPtrRef, that always points to the last pointer of the result list. This solves the same case that the dummy node did — dealing with the result list when it is empty. If you are trying to build up a list at its tail, either the dummy node or the struct node** "reference" strategy can be used (see Section 1 for details). struct node* SortedMerge2(struct node* a, struct node* b) { struct node* result = NULL; struct node** lastPtrRef = &result; // point to the last result pointer while (1) { if (a==NULL) { *lastPtrRef = b; break; } else if (b==NULL) { *lastPtrRef = a; break; } if (a->data data) { MoveNode(lastPtrRef, &a); } else { MoveNode(lastPtrRef, &b); } lastPtrRef = &((*lastPtrRef)->next);

// tricky: advance to point to // the next ".next" field

} return(result); }

SortedMerge() Using Recursion Merge() is one of those nice recursive problems where the recursive solution code is much cleaner than the iterative code. You probably wouldn't want to use the recursive version for production code however, because it will use stack space which is proportional to the length of the lists. struct node* SortedMerge3(struct node* a, struct node* b) { struct node* result = NULL;

31
// Base cases if (a==NULL) return(b); else if (b==NULL) return(a); // Pick either a or b, and recur if (a->data data) { result = a; result->next = SortedMerge3(a->next, b); } else { result = b; result->next = SortedMerge3(a, b->next); } return(result); }

15 — MergeSort() Solution
The MergeSort strategy is: split into sublists, sort the sublists recursively, merge the two sorted lists together to form the answer. void MergeSort(struct node** headRef) { struct node* head = *headRef; struct node* a; struct node* b; // Base case -- length 0 or 1 if ((head == NULL) || (head->next == NULL)) { return; } FrontBackSplit(head, &a, &b); // Split head into 'a' and 'b' sublists // We could just as well use AlternatingSplit()

MergeSort(&a); // Recursively sort the sublists MergeSort(&b); *headRef } = SortedMerge(a, b); // answer = merge the two sorted lists together

(Extra for experts) Using recursive stack space proportional to the length of a list is not recommended. However, the recursion in this case is ok — it uses stack space which is proportional to the log of the length of the list. For a 1000 node list, the recursion will only go about 10 deep. For a 2000 node list, it will go 11 deep. If you think about it, you can see that doubling the size of the list only increases the depth by 1.

16 — SortedIntersect() Solution
The strategy is to advance up both lists and build the result list as we go. When the current point in both lists are the same, add a node to the result. Otherwise, advance whichever list is smaller. By exploiting the fact that both lists are sorted, we only traverse each list once. To build up the result list, both the dummy node and local reference strategy solutions are shown...
// This solution uses the temporary dummy to build up the result list struct node* SortedIntersect(struct node* a, struct node* b) { struct node dummy;

32 struct node* tail = &dummy; dummy.next = NULL; // Once one or the other list runs out -- we're done while (a!=NULL && b!=NULL) { if (a->data == b->data) { Push((&tail->next), a->data); tail = tail->next; a = a->next; b = b->next; } else if (a->data < b->data) { // advance the smaller list a = a->next; } else { b = b->next; } } return(dummy.next); }

// This solution uses the local reference struct node* SortedIntersect2(struct node* a, struct node* b) { struct node* result = NULL; struct node** lastPtrRef = &result; // Advance comparing the first nodes in both lists. // When one or the other list runs out, we're done. while (a!=NULL && b!=NULL) { if (a->data == b->data) { // found a node for the intersection Push(lastPtrRef, a->data); lastPtrRef = &((*lastPtrRef)->next); a=a->next; b=b->next; } else if (a->data < b->data) { // advance the smaller list a=a->next; } else { b=b->next; } } return(result); }

17 — Reverse() Solution
This first solution uses the "Push" strategy with the pointer re-arrangement hand coded inside the loop. There's a slight trickyness in that it needs to save the value of the "current->next" pointer at the top of the loop since the body of the loop overwrites that pointer.
/* Iterative list reverse. Iterate through the list left-right.

33
Move/insert each node to the front of the result list -like a Push of the node. */ static void Reverse(struct node** headRef) { struct node* result = NULL; struct node* current = *headRef; struct node* next; while (current != NULL) { next = current->next; current->next = result; result = current; current = next; } *headRef = result; }

// tricky: note the next node // move the node onto the result

Here's the variation on the above that uses MoveNode() to do the work... static void Reverse2(struct node** headRef) { struct node* result = NULL; struct node* current = *headRef; while (current != NULL) { MoveNode(&result, ¤t); } *headRef = result; }

Finally, here's the back-middle-front strategy...
// Reverses the given linked list by changing its .next pointers and // its head pointer. Takes a pointer (reference) to the head pointer. void Reverse(struct node** headRef) { if (*headRef != NULL) { // special case: skip the empty list /* Plan for down the down the For each three to */

this loop: move three pointers: front, middle, back list in order. Middle is the main pointer running list. Front leads it and Back trails it. step, reverse the middle pointer and then advance all get the next node.

struct node* middle = *headRef; struct node* front = middle->next; struct node* back = NULL;

// the main pointer // the two other pointers (NULL ok)

while (1) { middle->next = back; if (front == NULL) break;

// fix the middle node // test if done

34

back = middle; middle = front; front = front->next; } *headRef = middle; } }

// advance the three pointers

// fix the head pointer to point to the new front

18 — RecursiveReverse() Solution
Probably the hardest part is accepting the concept that the RecursiveReverse(&rest) does in fact reverse the rest. Then then there's a trick to getting the one front node all the way to the end of the list. Make a drwaing to see how the trick works. void RecursiveReverse(struct node** headRef) { struct node* first; struct node* rest; if (*headRef == NULL) return; first = *headRef; rest = first->next; // empty list base case

// suppose first = {1, 2, 3} // rest = {2, 3} // empty rest base case // Recursively reverse the smaller {2, 3} case // after: rest = {3, 2}

if (rest == NULL) return; RecursiveReverse(&rest);

first->next->next = first; // put the first elem on the end of the list first->next = NULL; // (tricky step -- make a drawing) *headRef = rest; } // fix the head pointer

The inefficient soluition is to reverse the last n-1 elements of the list, and then iterate all the way down to the new tail and put the old head node there. That solution is very slow compared to the above which gets the head node in the right place without extra iteration.

35

Appendix
Basic Utility Function Implementations Here is the source code for the basic utility functions.
Length() // Return the number of nodes in a list int Length(struct node* head) { int count = 0; struct node* current = head; while (current != NULL) { count++; current=current->next; } return(count); }

Push() // Given a reference (pointer to pointer) to the head // of a list and an int, push a new node on the front of the list. // Creates a new node with the int, links the list off the .next of the // new node, and finally changes the head to point to the new node. void Push(struct node** headRef, int newData) { struct node* newNode = (struct node*) malloc(sizeof(struct node)); // allocate node newNode->data = newData; // put in the data newNode->next = (*headRef); // link the old list off the new node (*headRef) = newNode; // move the head to point to the new node }

BuildOneTwoThree() // Build and return the list {1, 2, 3} struct node* BuildOneTwoThree() { struct node* head = NULL; // Start with the empty list Push(&head, 3); // Use Push() to add all the data Push(&head, 2); Push(&head, 1); return(head); }

Similar Documents

Free Essay

Mfrkkwl

...on. These groups can be conveniently represented as elements of arrays. The declaration of array includes the type of array that is the type of value we are going to store in it, the array name and maximum number of elements. Examples: short val[200]; val[12] = 5;   Declaration & Data Types Arrays have the same data types as variables, i.e., short, long, float etc. They are similar to variables: they can either be declared global or local. They are declared by the given syntax: Datatype array_name [dimensions] = {element1,element2,….,element} The declaration form of one-dimensional array is Data_type array_name [size]; The following declares an array called ‘numbers’ to hold 5 integers and sets the first and last elements. C arrays are always indexed from 0. So the first integer in ‘numbers’ array is numbers[0] and the last is numbers[4]. int numbers [5]; numbers [0] = 1; // set first element numbers [4] = 5; This array contains 5 elements. Any...

Words: 7409 - Pages: 30

Free Essay

Competency Matrix

...Array and LinkedList Able to explain and use Arrays, LinkedLists, Dictionaries etc in practical programming tasks Knows space and time tradeoffs of the basic data structures, Arrays vs LinkedLists, Able to explain how hashtables can be implemented and can handle collisions, Priority queues and ways to implement them etc. Knowledge of advanced data structures like B-trees, binomial and fibonacci heaps, AVL/Red Black trees, Splay Trees, Skip Lists, tries etc. algorithms Unable to find the average of numbers in an array (It’s hard to believe but I’ve interviewed such candidates) Basic sorting, searching and data structure traversal and retrieval algorithms Tree, Graph, simple greedy and divide and conquer algorithms, is able to understand the relevance of the levels of this matrix. systems programming Doesn’t know what a compiler, linker or interpreter is Basic understanding of compilers, linker and interpreters. Understands Understands kernel mode vs. user mode, multi-threading, synchronization primitives and how they’re implemented, able to read what assembly code is and how things work at the hardware level. Some assembly code. Understands how networks work, understanding of network protocols and socket level programming. knowledge of virtual memory and paging. Able to recognize and code dynamic programming solutions, good knowledge of graph algorithms, good knowledge of numerical computation algorithms, able to identify NP problems etc. ...

Words: 1812 - Pages: 8

Free Essay

Lol Girl

...Blue Pelican Java by Charles E. Cook Version 3.0.5h Copyright © 2004 - 2008 by Charles E. Cook; Refugio, Tx (All rights reserved) 1-1 “Blue Pelican Java,” by Charles E. Cook. ISBN 1-58939-758-4. Published 2005 by Virtualbookworm.com Publishing Inc., P.O. Box 9949, College Station, Tx 77842, US. ©2005, Charles E. Cook. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, recording or otherwise, without the prior written permission of Charles E. Cook. Manufactured in the United States of America. Preface You will find this book to be somewhat unusual. Most computer science texts will begin with a section on the history of computers and then with a flurry of definitions that are just “so many words” to the average student. My approach with Blue Pelican Java is to first give the student some experience upon which to hang the definitions that come later, and consequently, make them more meaningful. This book does have a history section in Appendix S and plenty of definitions later when the student is ready for them. If you will look at Lesson 1, you will see that we go right to work and write a program the very first day. The student will not understand several things about that first program, yet he can immediately make the computer do something useful. This work ethic is typical of the remainder of the book. Rest assured that full understanding...

Words: 31284 - Pages: 126

Premium Essay

Java

...JMaster list of Java interview questions - 115 questions By admin | July 18, 2005 115 questions total, not for the weak. Covers everything from basics to JDBC connectivity, AWT and JSP. 1. What is the difference between procedural and object-oriented programs?- a) In procedural program, programming logic follows certain procedures and the instructions are executed one after another. In OOP program, unit of program is object, which is nothing but combination of data and code. b) In procedural program, data is exposed to the whole program whereas in OOPs program, it is accessible with in the object and which in turn assures the security of the code. 2. What are Encapsulation, Inheritance and Polymorphism?- Encapsulation is the mechanism that binds together code and data it manipulates and keeps both safe from outside interference and misuse. Inheritance is the process by which one object acquires the properties of another object. Polymorphism is the feature that allows one interface to be used for general class actions. 3. What is the difference between Assignment and Initialization?- Assignment can be done as many times as desired whereas initialization can be done only once. 4. What is OOPs?- Object oriented programming organizes a program around its data, i. e. , objects and a set of well defined interfaces to that data. An object-oriented program can be characterized as data controlling 5. access to code. What are Class, Constructor...

Words: 6762 - Pages: 28

Free Essay

Exercise Java

...Programming Exercises For Chapter 2 -------------------------------------------------------------------------------- THIS PAGE CONTAINS programming exercises based on material from Chapter 2 of this on-line Java textbook. Each exercise has a link to a discussion of one possible solution of that exercise. http://www.java2s.clanteam.com -------------------------------------------------------------------------------- Exercise 2.1: Write a program that will print your initials to standard output in letters that are nine lines tall. Each big letter should be made up of a bunch of *'s. For example, if your initials were "DJE", then the output would look something like: ****** ************* ********** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ******** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ***** **** ********** See the solution! : visit this website http://java2s.clanteam.com/ -------------------------------------------------------------------------------- Exercise 2.2: Write a program that simulates rolling a pair of dice. You can simulate rolling one die by choosing one of the integers 1, 2...

Words: 18137 - Pages: 73

Free Essay

Java Programming

...A Programmer’s Guide to Java™ SCJP Certification Third Edition This page intentionally left blank A Programmer’s Guide to Java™ SCJP Certification A Comprehensive Primer Third Edition Khalid A. Mughal Rolf W. Rasmussen Upper Saddle River, New Jersey • Boston • Indianapolis • San Francisco New York • Toronto • Montreal • London • Munich • Paris • Madrid Capetown • Sidney • Tokyo • Singapore • Mexico City Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. The authors and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. The publisher offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales, which may include electronic versions and/or custom covers and content particular to your business, training goals, marketing focus, and branding interests. For more information, please contact: U.S. Corporate and Government Sales (800) 382-3419 corpsales@pearsontechgroup.com For sales outside the United...

Words: 15086 - Pages: 61

Premium Essay

Cmmkfgdk

...CRACKING THE FOURTH EDITION INTERVIEW 150 programming interview questions and solutions Plus: • Five proven approaches to solving tough algorithm questions • Ten mistakes candidates make -- and how to avoid them • Steps to prepare for behavioral and technical questions • Interviewer war stories: a view from the interviewer’s side CODING GAYLE LAAKMANN Founder and CEO, CareerCup.com CRACKING THE CODING INTERVIEW CRACKING THE INTERVIEW 150 Programming Interview Questions and Solutions CODING GAYLE LAAKMANN Founder and CEO, CareerCup.com CareerCup, LLC Seattle, WA CRACKING THE CODING INTERVIEW, FOURTH EDITION Copyright © 2008 - 2010 by Gayle Laakmann. All rights reserved. Published by CareerCup, LLC, Seattle, WA. Version 3.21090410302210. Visit our website at: www.careercup.com. No part of this book may be used or reproduced in any manner without written permission except in the case of brief quotations in critical articles or reviews. For more information, contact support@careercup.com. Printed in United States of America 978-1-450-59320-5 9781450593205 (ISBN 13) Table of Contents Foreword Introduction Behind the Scenes The Microsoft Interview The Amazon Interview The Google Interview The Apple Interview The Yahoo Interview Interview War Stories Before the Interview Resume Advice Behavioral Preparation Technical Preparation The Interview and Beyond Handling Behavioral Questions Handling Technical Questions Five Algorithm Approaches...

Words: 47808 - Pages: 192

Premium Essay

Velocity

...TE AM FL Y Mastering Apache Velocity Joseph D. Gradecki Jim Cole Wiley Publishing, Inc. Mastering Apache Velocity Joseph D. Gradecki Jim Cole Wiley Publishing, Inc. Publisher: Joe Wikert Copyeditor: Elizabeth Welch Executive Editor: Robert Elliott Compositors: Gina Rexrode and Amy Hassos Editorial Manager: Kathryn Malm Managing Editor: Vincent Kunkemueller Book Producer: Ryan Publishing Group, Inc. Copyright © 2003 by Joseph D. Gradecki and Jim Cole. All rights reserved. Published by Wiley Publishing, Inc., Indianapolis, Indiana Published simultaneously in Canada No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8700. Requests to the Publisher for permission should be addressed to the Legal Department, Wiley Publishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4447, E-mail: permcoordinator@wiley.com. Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations...

Words: 70755 - Pages: 284

Free Essay

Design Pattern

................................................................ 9 Guide to Readers .................................................... 10 1 Introduction ...................................................... 11 1.1 What Is a Design Pattern? ...................................... 12 1.2 Design Patterns in Smalltalk MVC ............................... 14 1.3 Describing Design Patterns ..................................... 16 1.4 The Catalog of Design Patterns ................................. 18 1.5 Organizing the Catalog ......................................... 21 1.6 How Design Patterns Solve Design Problems ...................... 23 1.7 How to Select a Design Pattern ................................. 42 1.8 How to Use a Design Pattern .................................... 44 2 A Case Study: Designing a Document Editor ......................... 46 2.1 Design Problems ................................................ 46 2.2 Document Structure ............................................. 47 2.3 Formatting ..................................................... 53 2.4 Embellishing the User Interface ................................ 56 2.5 Supporting Multiple Look-and-Feel Standards .................... 60 2.6 Supporting Multiple Window Systems ............................. 64 2.7 User Operations ................................................ 72 2.8 Spelling Checking and Hyphenation .............................. 77 2.9 Summary ...............................................

Words: 84976 - Pages: 340

Free Essay

Research Paper

... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxix Chapter 1 Before the Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Chapter 2 The Job Application Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Chapter 3 Approaches to Programming Problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Chapter 4 Linked Lists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Chapter 5 Trees and Graphs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Chapter 6 Arrays and Strings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Chapter 7 Recursion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...

Words: 48008 - Pages: 193

Premium Essay

Java

...Release Team[oR] 2001 [x] java Java 2: The Complete Reference by Patrick Naughton and Herbert Schildt Osborne/McGraw-Hill © 1999, 1108 pages ISBN: 0072119764 This thorough reference reads like a helpful friend. Includes servlets, Swing, and more. Table of Contents Back Cover Synopsis by Rebecca Rohan Java 2: The Complete Reference blends the expertise found in Java 1: The Complete Reference with Java 2 topics such as "servlets" and "Swing." As before, there's help with Java Beans and migrating from C++ to Java. A special chapter gives networking basics and breaks out networking-related classes. This book helps you master techniques by doing as well as reading. Projects include a multi-player word game with attention paid to network security. The book is updated where appropriate throughout, and the rhythm of text, code, tables, and illustrations is superb. It's a valuable resource for the developer who is elbow-deep in demanding projects. Table of Contents Java 2 Preface - 7 Part l The Java Language - The Complete Reference - 4 Chapter 1 Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 7 Chapter 8 Chapter 9 hapter 10 - The Genesis of Java - 9 - An Overview of Java - 20 - Data Types, Variables, and Arrays - 36 - Operators - 57 - Control Statements - 75 - Introducing Classes - 94 - A Closer Look at Methods and Classes - 111 - Inheritance - 134 - Packages and Interfaces - 156 - Exception Handling - 174 Chapter 11 - Multithreaded Programming...

Words: 78285 - Pages: 314