Notes
Notes
James Aspnes
Contents
0.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
0.1.1 License . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
0.1.2 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
0.1.3 Documentation . . . . . . . . . . . . . . . . . . . . . . . . 13
0.1.4 Questions and comments . . . . . . . . . . . . . . . . . . 13
0.2 Lecture schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
0.2.1 Topics by date . . . . . . . . . . . . . . . . . . . . . . . . 13
0.2.2 Topics not covered in 2015 . . . . . . . . . . . . . . . . . 16
0.3 Syllabus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
0.3.1 On-line course information . . . . . . . . . . . . . . . . . 16
0.3.2 Meeting times . . . . . . . . . . . . . . . . . . . . . . . . . 17
0.3.3 Synopsis of the course . . . . . . . . . . . . . . . . . . . . 17
0.3.4 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . 17
0.3.5 Textbook . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
0.3.6 Course requirements . . . . . . . . . . . . . . . . . . . . . 17
0.3.7 Staff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
0.3.7.1 Instructor . . . . . . . . . . . . . . . . . . . . . . 18
0.3.7.2 Teaching Fellows . . . . . . . . . . . . . . . . . . 18
0.3.7.3 Peer tutors . . . . . . . . . . . . . . . . . . . . . 18
0.3.8 Use of outside help . . . . . . . . . . . . . . . . . . . . . . 18
0.3.9 Clarifications for homework assignments . . . . . . . . . . 18
0.3.10 Late assignments . . . . . . . . . . . . . . . . . . . . . . . 18
0.4 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
0.4.1 Why should you learn to program in C? . . . . . . . . . . 19
0.4.2 Why should you learn about data structures and program-
ming techniques? . . . . . . . . . . . . . . . . . . . . . . . 20
1
1.3.1 Access using FastX . . . . . . . . . . . . . . . . . . . . . . 21
1.3.1.1 Getting a license key . . . . . . . . . . . . . . . 21
1.3.1.2 FastX in the Zoo Annex . . . . . . . . . . . . . . 21
1.3.1.3 Using FastX from Windows . . . . . . . . . . . . 23
1.3.1.4 Using FastX from OSX . . . . . . . . . . . . . . 24
1.3.2 Terminal access . . . . . . . . . . . . . . . . . . . . . . . . 25
1.3.3 GUI access . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.4 How to compile and run programs . . . . . . . . . . . . . . . . . 28
1.4.1 Creating the program . . . . . . . . . . . . . . . . . . . . 28
1.4.2 Compiling and running a program . . . . . . . . . . . . . 28
1.4.3 Some notes on what the program does . . . . . . . . . . . 29
2
2.4.4.2 Automated testing . . . . . . . . . . . . . . . . . 53
2.4.4.3 Examples of some common valgrind errors . . . 53
2.4.4.3.1 Uninitialized values . . . . . . . . . . . 53
2.4.4.3.2 Bytes definitely lost . . . . . . . . . . . 54
2.4.4.3.3 Invalid write or read operations . . . . 55
2.4.5 Not recommended: debugging output . . . . . . . . . . . 57
2.5 Performance tuning . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.5.1 Timing under Linux . . . . . . . . . . . . . . . . . . . . . 59
2.5.2 Profiling with gprof . . . . . . . . . . . . . . . . . . . . . 60
2.5.2.1 Effect of optimization during compilation . . . . 68
2.6 Version control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
2.6.1 Setting up Git . . . . . . . . . . . . . . . . . . . . . . . . 69
2.6.2 Editing files . . . . . . . . . . . . . . . . . . . . . . . . . . 71
2.6.3 Renaming files . . . . . . . . . . . . . . . . . . . . . . . . 72
2.6.4 Adding and removing files . . . . . . . . . . . . . . . . . . 73
2.6.5 Recovering files from the repository . . . . . . . . . . . . 74
2.6.6 Undoing bad commits . . . . . . . . . . . . . . . . . . . . 74
2.6.7 Looking at old versions . . . . . . . . . . . . . . . . . . . 75
2.6.8 More information about Git . . . . . . . . . . . . . . . . . 76
2.7 Submitting assignments . . . . . . . . . . . . . . . . . . . . . . . 76
3
3.3 Operator precedence . . . . . . . . . . . . . . . . . . . . . . . . . 105
3.4 Programming style . . . . . . . . . . . . . . . . . . . . . . . . . . 106
3.5 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
3.5.1 Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
3.5.2 Variables as names . . . . . . . . . . . . . . . . . . . . . . 108
3.5.2.1 Variable declarations . . . . . . . . . . . . . . . 109
3.5.2.2 Variable names . . . . . . . . . . . . . . . . . . . 110
3.5.3 Using variables . . . . . . . . . . . . . . . . . . . . . . . . 112
3.5.4 Initialization . . . . . . . . . . . . . . . . . . . . . . . . . 113
3.5.5 Storage class qualifiers . . . . . . . . . . . . . . . . . . . . 114
3.5.5.1 Scope and extent . . . . . . . . . . . . . . . . . . 114
3.5.5.1.1 Additional qualifiers for global variables 114
3.5.6 Marking variables as constant . . . . . . . . . . . . . . . . 115
3.5.6.1 Pointers to const . . . . . . . . . . . . . . . . . 115
3.6 Input and output . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
3.6.1 Character streams . . . . . . . . . . . . . . . . . . . . . . 116
3.6.2 Reading and writing single characters . . . . . . . . . . . 117
3.6.3 Formatted I/O . . . . . . . . . . . . . . . . . . . . . . . . 118
3.6.4 Rolling your own I/O routines . . . . . . . . . . . . . . . 120
3.6.5 File I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
3.7 Statements and control structures . . . . . . . . . . . . . . . . . . 124
3.7.1 Simple statements . . . . . . . . . . . . . . . . . . . . . . 124
3.7.2 Compound statements . . . . . . . . . . . . . . . . . . . . 124
3.7.2.1 Conditionals . . . . . . . . . . . . . . . . . . . . 125
3.7.2.2 Loops . . . . . . . . . . . . . . . . . . . . . . . . 127
3.7.2.2.1 The while loop . . . . . . . . . . . . . . 127
3.7.2.2.2 The do..while loop . . . . . . . . . . . . 128
3.7.2.2.3 The for loop . . . . . . . . . . . . . . . 129
3.7.2.2.4 Loops with break, continue, and goto . 130
3.7.2.3 Choosing where to put a loop exit . . . . . . . . 131
3.8 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
3.8.1 Function definitions . . . . . . . . . . . . . . . . . . . . . 132
3.8.2 When to write a function . . . . . . . . . . . . . . . . . . 134
3.8.3 Calling a function . . . . . . . . . . . . . . . . . . . . . . 136
3.8.4 The return statement . . . . . . . . . . . . . . . . . . . . 136
3.8.5 Function declarations and modules . . . . . . . . . . . . . 137
3.8.6 Static functions . . . . . . . . . . . . . . . . . . . . . . . . 138
3.8.7 Local variables . . . . . . . . . . . . . . . . . . . . . . . . 139
3.8.8 Mechanics of function calls . . . . . . . . . . . . . . . . . 140
3.9 Pointers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
3.9.1 Memory and addresses . . . . . . . . . . . . . . . . . . . . 141
3.9.2 Pointer variables . . . . . . . . . . . . . . . . . . . . . . . 141
3.9.2.1 Declaring a pointer variable . . . . . . . . . . . . 141
3.9.2.2 Assigning to pointer variables . . . . . . . . . . 142
3.9.2.3 Using a pointer . . . . . . . . . . . . . . . . . . . 142
3.9.2.4 Printing pointers . . . . . . . . . . . . . . . . . . 143
4
3.9.3 The null pointer . . . . . . . . . . . . . . . . . . . . . . . 144
3.9.4 Pointers and functions . . . . . . . . . . . . . . . . . . . . 144
3.9.5 Pointer arithmetic and arrays . . . . . . . . . . . . . . . . 147
3.9.5.1 Arrays . . . . . . . . . . . . . . . . . . . . . . . 148
3.9.5.2 Arrays and functions . . . . . . . . . . . . . . . 149
3.9.5.3 Multidimensional arrays . . . . . . . . . . . . . . 150
3.9.5.4 Variable-length arrays . . . . . . . . . . . . . . . 153
3.9.6 Void pointers . . . . . . . . . . . . . . . . . . . . . . . . . 156
3.9.6.1 Alignment . . . . . . . . . . . . . . . . . . . . . 157
3.9.7 Run-time storage allocation using malloc . . . . . . . . . 158
3.9.8 Function pointers . . . . . . . . . . . . . . . . . . . . . . . 161
3.9.8.1 Function pointer declarations . . . . . . . . . . . 161
3.9.8.2 Callbacks . . . . . . . . . . . . . . . . . . . . . . 162
3.9.8.3 Dispatch tables . . . . . . . . . . . . . . . . . . . 163
3.9.9 The restrict keyword . . . . . . . . . . . . . . . . . . . . . 164
3.10 Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
3.10.1 C strings . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
3.10.2 String constants . . . . . . . . . . . . . . . . . . . . . . . 166
3.10.3 String buffers . . . . . . . . . . . . . . . . . . . . . . . . . 167
3.10.3.1 String buffers and the perils of gets . . . . . . . 167
3.10.4 Operations on strings . . . . . . . . . . . . . . . . . . . . 169
3.10.5 Finding the length of a string . . . . . . . . . . . . . . . . 171
3.10.5.1 The strlen tarpit . . . . . . . . . . . . . . . . . . 172
3.10.6 Comparing strings . . . . . . . . . . . . . . . . . . . . . . 173
3.10.7 Formatted output to strings . . . . . . . . . . . . . . . . . 174
3.10.8 Dynamic allocation of strings . . . . . . . . . . . . . . . . 174
3.10.9 Command-line arguments . . . . . . . . . . . . . . . . . . 175
3.11 Structured data types . . . . . . . . . . . . . . . . . . . . . . . . 176
3.11.1 Structs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
3.11.1.1 Operations on structs . . . . . . . . . . . . . . . 179
3.11.1.2 Layout in memory . . . . . . . . . . . . . . . . . 180
3.11.1.3 Bit fields . . . . . . . . . . . . . . . . . . . . . . 180
3.11.2 Unions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
3.11.3 Enums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
3.11.3.1 Specifying particular values . . . . . . . . . . . . 183
3.11.3.2 What most people do . . . . . . . . . . . . . . . 183
3.11.3.3 Using enum with union . . . . . . . . . . . . . . 183
3.12 Type aliases using typedef . . . . . . . . . . . . . . . . . . . . . 184
3.12.1 Opaque structs . . . . . . . . . . . . . . . . . . . . . . . . 185
3.13 Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
3.13.1 Macros with arguments . . . . . . . . . . . . . . . . . . . 187
3.13.1.1 Multiple arguments . . . . . . . . . . . . . . . . 188
3.13.1.2 Perils of repeating arguments . . . . . . . . . . . 188
3.13.1.3 Variable-length argument lists . . . . . . . . . . 188
3.13.1.4 Macros vs. inline functions . . . . . . . . . . . . 189
3.13.2 Macros that include other macros . . . . . . . . . . . . . . 190
5
3.13.3 More specialized macros . . . . . . . . . . . . . . . . . . . 190
3.13.3.1 Multiple expressions in a macro . . . . . . . . . 190
3.13.3.2 Non-syntactic macros . . . . . . . . . . . . . . . 191
3.13.3.3 Multiple statements in one macro . . . . . . . . 191
3.13.3.4 String expansion . . . . . . . . . . . . . . . . . . 192
3.13.3.5 Big macros . . . . . . . . . . . . . . . . . . . . . 193
3.13.4 Conditional compilation . . . . . . . . . . . . . . . . . . . 194
3.13.5 Defining macros on the command line . . . . . . . . . . . 195
3.13.6 The #if directive . . . . . . . . . . . . . . . . . . . . . . . 196
3.13.7 Debugging macro expansions . . . . . . . . . . . . . . . . 196
3.13.8 Can a macro call a preprocessor command? . . . . . . . . 197
6
4.4.4.3 Universal hashing . . . . . . . . . . . . . . . . . 236
4.4.5 Maintaining a constant load factor . . . . . . . . . . . . . 238
4.4.6 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
4.4.6.1 A low-overhead hash table using open addressing 238
4.4.6.2 A string to string dictionary using chaining . . . 241
4.5 Generic containers . . . . . . . . . . . . . . . . . . . . . . . . . . 246
4.5.1 Generic dictionary: interface . . . . . . . . . . . . . . . . 247
4.5.2 Generic dictionary: implementation . . . . . . . . . . . . 249
4.6 Recursion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
4.6.1 Example of recursion in C . . . . . . . . . . . . . . . . . . 257
4.6.2 Common problems with recursion . . . . . . . . . . . . . 261
4.6.2.1 Omitting the base case . . . . . . . . . . . . . . 261
4.6.2.2 Blowing out the stack . . . . . . . . . . . . . . . 262
4.6.2.3 Failure to make progress . . . . . . . . . . . . . 262
4.6.3 Tail-recursion and iteration . . . . . . . . . . . . . . . . . 263
4.6.3.1 Binary search: recursive and iterative versions . 264
4.6.4 Mergesort: a recursive sorting algorithm . . . . . . . . . . 266
4.6.5 Asymptotic complexity of recursive functions . . . . . . . 268
4.7 Binary trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
4.7.1 Tree basics . . . . . . . . . . . . . . . . . . . . . . . . . . 269
4.7.2 Binary tree implementations . . . . . . . . . . . . . . . . 270
4.7.3 The canonical binary tree algorithm . . . . . . . . . . . . 271
4.7.4 Nodes vs leaves . . . . . . . . . . . . . . . . . . . . . . . . 272
4.7.5 Special classes of binary trees . . . . . . . . . . . . . . . . 272
4.8 Heaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
4.8.1 Priority queues . . . . . . . . . . . . . . . . . . . . . . . . 273
4.8.2 Expensive implementations of priority queues . . . . . . . 273
4.8.3 Structure of a heap . . . . . . . . . . . . . . . . . . . . . . 273
4.8.4 Packed heaps . . . . . . . . . . . . . . . . . . . . . . . . . 274
4.8.5 Bottom-up heapification . . . . . . . . . . . . . . . . . . . 274
4.8.6 Heapsort . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
4.8.7 More information . . . . . . . . . . . . . . . . . . . . . . . 277
4.9 Binary search trees . . . . . . . . . . . . . . . . . . . . . . . . . . 277
4.9.1 Searching for a node . . . . . . . . . . . . . . . . . . . . . 278
4.9.2 Inserting a new node . . . . . . . . . . . . . . . . . . . . . 278
4.9.3 Deleting a node . . . . . . . . . . . . . . . . . . . . . . . . 279
4.9.4 Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
4.10 Augmented trees . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
4.10.1 Applications . . . . . . . . . . . . . . . . . . . . . . . . . 280
4.11 Balanced trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
4.11.1 Tree rotations . . . . . . . . . . . . . . . . . . . . . . . . . 281
4.11.2 AVL trees . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
4.11.2.1 Sample implementation . . . . . . . . . . . . . . 284
4.11.3 2–3 trees . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
4.11.4 Red-black trees . . . . . . . . . . . . . . . . . . . . . . . . 296
4.11.5 B-trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
7
4.11.6 Splay trees . . . . . . . . . . . . . . . . . . . . . . . . . . 299
4.11.6.1 How splaying works . . . . . . . . . . . . . . . . 299
4.11.6.2 Analysis . . . . . . . . . . . . . . . . . . . . . . 300
4.11.6.3 Other operations . . . . . . . . . . . . . . . . . . 301
4.11.6.4 Top-down splaying . . . . . . . . . . . . . . . . . 301
4.11.6.5 An implementation . . . . . . . . . . . . . . . . 304
4.11.6.6 More information . . . . . . . . . . . . . . . . . 311
4.11.7 Scapegoat trees . . . . . . . . . . . . . . . . . . . . . . . . 311
4.11.8 Skip lists . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
4.11.9 Implementations . . . . . . . . . . . . . . . . . . . . . . . 311
4.12 Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
4.12.1 Basic definitions . . . . . . . . . . . . . . . . . . . . . . . 312
4.12.2 Why graphs are useful . . . . . . . . . . . . . . . . . . . . 312
4.12.3 Operations on graphs . . . . . . . . . . . . . . . . . . . . 315
4.12.4 Representations of graphs . . . . . . . . . . . . . . . . . . 315
4.12.4.1 Adjacency matrices . . . . . . . . . . . . . . . . 315
4.12.4.2 Adjacency lists . . . . . . . . . . . . . . . . . . . 315
4.12.4.2.1 An implementation . . . . . . . . . . . 316
4.12.4.3 Implicit representations . . . . . . . . . . . . . . 321
4.12.5 Searching for paths in a graph . . . . . . . . . . . . . . . 321
4.12.5.1 Implementation of depth-first and breadth-first
search . . . . . . . . . . . . . . . . . . . . . . . . 323
4.12.5.2 Combined implementation of depth-first and
breadth-first search . . . . . . . . . . . . . . . . 327
4.12.5.3 Other variations on the basic algorithm . . . . . 335
4.13 Dynamic programming . . . . . . . . . . . . . . . . . . . . . . . . 335
4.13.1 Memoization . . . . . . . . . . . . . . . . . . . . . . . . . 336
4.13.2 Dynamic programming . . . . . . . . . . . . . . . . . . . . 337
4.13.2.1 More examples . . . . . . . . . . . . . . . . . . . 338
4.13.2.1.1 Longest increasing subsequence . . . . . 338
4.13.2.1.2 All-pairs shortest paths . . . . . . . . . 341
4.13.2.1.3 Longest common subsequence . . . . . 342
4.14 Randomization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
4.14.1 Generating random values in C . . . . . . . . . . . . . . . 345
4.14.1.1 The rand function from the standard library . . 345
4.14.1.1.1 Supplying a seed with srand . . . . . . 346
4.14.1.2 Better pseudorandom number generators . . . . 347
4.14.1.3 Random numbers without the pseudo . . . . . . 347
4.14.1.4 Range issues . . . . . . . . . . . . . . . . . . . . 348
4.14.2 Randomized algorithms . . . . . . . . . . . . . . . . . . . 351
4.14.2.1 Randomized search . . . . . . . . . . . . . . . . 351
4.14.2.2 Quickselect and quicksort . . . . . . . . . . . . . 352
4.14.3 Randomized data structures . . . . . . . . . . . . . . . . . 355
4.14.3.1 Skip lists . . . . . . . . . . . . . . . . . . . . . . 356
4.14.3.2 Universal hash families . . . . . . . . . . . . . . 360
4.15 String processing . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
8
4.15.1 Radix search . . . . . . . . . . . . . . . . . . . . . . . . . 362
4.15.1.1 Tries . . . . . . . . . . . . . . . . . . . . . . . . 362
4.15.1.1.1 Searching a trie . . . . . . . . . . . . . 363
4.15.1.1.2 Inserting a new element into a trie . . . 363
4.15.1.1.3 Implementation . . . . . . . . . . . . . 363
4.15.1.2 Patricia trees . . . . . . . . . . . . . . . . . . . . 369
4.15.1.3 Ternary search trees . . . . . . . . . . . . . . . . 371
4.15.1.4 More information . . . . . . . . . . . . . . . . . 374
4.15.2 Radix sort . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
4.15.2.1 Bucket sort . . . . . . . . . . . . . . . . . . . . . 375
4.15.2.2 Classic LSB radix sort . . . . . . . . . . . . . . . 375
4.15.2.3 MSB radix sort . . . . . . . . . . . . . . . . . . . 376
4.15.2.3.1 Issues with recursion depth . . . . . . . 376
4.15.2.3.2 Implementing the buckets . . . . . . . . 376
4.15.2.3.3 Further optimization . . . . . . . . . . 377
4.15.2.3.4 Sample implementation . . . . . . . . . 377
9
5.5 Testing during development . . . . . . . . . . . . . . . . . . . . . 417
5.5.1 Unit tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
5.5.1.1 What to put in the test code . . . . . . . . . . . 418
5.5.1.2 Example . . . . . . . . . . . . . . . . . . . . . . 418
5.5.2 Test harnesses . . . . . . . . . . . . . . . . . . . . . . . . 422
5.5.2.1 Module interface . . . . . . . . . . . . . . . . . . 422
5.5.2.1.1 stack.h . . . . . . . . . . . . . . . . . . 422
5.5.2.2 Test code . . . . . . . . . . . . . . . . . . . . . . 423
5.5.2.2.1 test-stack.c . . . . . . . . . . . . . . . . 423
5.5.2.3 Makefile . . . . . . . . . . . . . . . . . . . . . . . 425
5.5.2.3.1 Makefile . . . . . . . . . . . . . . . . . . 425
5.5.3 Stub implementation . . . . . . . . . . . . . . . . . . . . . 426
5.5.3.1 stack.c . . . . . . . . . . . . . . . . . . . . . . . 426
5.5.4 Bounded-space implementation . . . . . . . . . . . . . . . 427
5.5.4.1 stack.c . . . . . . . . . . . . . . . . . . . . . . . 427
5.5.5 First fix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
5.5.6 Final version . . . . . . . . . . . . . . . . . . . . . . . . . 429
5.5.6.1 stack.c . . . . . . . . . . . . . . . . . . . . . . . 429
5.5.7 Moral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
5.5.8 Appendix: Test macros . . . . . . . . . . . . . . . . . . . 431
5.6 Algorithm design techniques . . . . . . . . . . . . . . . . . . . . . 436
5.6.1 Basic principles of algorithm design . . . . . . . . . . . . 436
5.6.2 Specific techniques . . . . . . . . . . . . . . . . . . . . . . 437
5.6.3 Example: Finding the maximum . . . . . . . . . . . . . . 438
5.6.4 Example: Sorting . . . . . . . . . . . . . . . . . . . . . . . 439
5.7 Bit manipulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
5.8 Persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
5.8.1 A simple solution using text files . . . . . . . . . . . . . . 441
5.8.2 Using a binary file . . . . . . . . . . . . . . . . . . . . . . 442
5.8.3 A version that updates the file in place . . . . . . . . . . 444
5.8.4 An even better version using mmap . . . . . . . . . . . . 445
5.8.5 Concurrency and fault-tolerance issues: ACIDity . . . . . 447
7 Assignments 455
7.1 Assignment 1, due Thursday 2015-01-29, at 11:00pm . . . . . . . 455
7.1.1 Bureaucratic part . . . . . . . . . . . . . . . . . . . . . . . 455
7.1.2 A rotten cipher . . . . . . . . . . . . . . . . . . . . . . . . 455
7.1.3 Your task . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
7.1.4 Hints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
7.1.5 Testing your assignment . . . . . . . . . . . . . . . . . . . 456
10
7.1.6 Submitting your assignment . . . . . . . . . . . . . . . . . 457
7.1.7 Sample solution . . . . . . . . . . . . . . . . . . . . . . . . 457
7.2 Assignment 2, due Wednesday 2015-02-04, at 11:00pm . . . . . . 458
7.2.1 Opening a safe . . . . . . . . . . . . . . . . . . . . . . . . 458
7.2.2 Submitting your assignment . . . . . . . . . . . . . . . . . 460
7.2.3 Valgrind . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
7.2.4 Sample solution . . . . . . . . . . . . . . . . . . . . . . . . 461
7.3 Assignment 3, due Wednesday 2015-02-11, at 11:00pm . . . . . . 463
7.3.1 Quadratic letter sequences . . . . . . . . . . . . . . . . . . 463
7.3.2 Your task . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
7.3.3 Submitting your assignment . . . . . . . . . . . . . . . . . 465
7.3.4 Sample solution . . . . . . . . . . . . . . . . . . . . . . . . 465
7.4 Assignment 4, due Wednesday 2015-02-18, at 11:00pm . . . . . . 468
7.4.1 An ASCII art compositor . . . . . . . . . . . . . . . . . . 468
7.4.2 Submitting your assignment . . . . . . . . . . . . . . . . . 469
7.4.3 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
7.4.3.1 Input . . . . . . . . . . . . . . . . . . . . . . . . 470
7.4.3.2 Output . . . . . . . . . . . . . . . . . . . . . . . 470
7.4.3.3 General . . . . . . . . . . . . . . . . . . . . . . . 470
7.4.4 Sample solution . . . . . . . . . . . . . . . . . . . . . . . . 471
7.5 Assignment 5, due Wednesday 2015-02-25, at 11:00pm . . . . . . 476
7.5.1 Build a Turing machine! . . . . . . . . . . . . . . . . . . . 476
7.5.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
7.5.3 Your task . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
7.5.4 Submitting your assignment . . . . . . . . . . . . . . . . . 478
7.5.5 Sample solution . . . . . . . . . . . . . . . . . . . . . . . . 478
7.6 Assignment 6, due Wednesday 2015-03-25, at 11:00pm . . . . . . 483
7.6.1 Sinking ships . . . . . . . . . . . . . . . . . . . . . . . . . 483
7.6.2 Things to watch out for . . . . . . . . . . . . . . . . . . . 484
7.6.3 The testShips program . . . . . . . . . . . . . . . . . . . 485
7.6.4 Submitting your assignment . . . . . . . . . . . . . . . . . 487
7.6.5 Provided source files . . . . . . . . . . . . . . . . . . . . . 487
7.6.6 Sample solution . . . . . . . . . . . . . . . . . . . . . . . . 490
7.7 Assignment 7, due Wednesday 2015-04-01, at 11:00pm . . . . . . 496
7.7.1 Solitaire with big cards . . . . . . . . . . . . . . . . . . . 496
7.7.2 Explanation of the testing program . . . . . . . . . . . . . 497
7.7.3 Submitting your assignment . . . . . . . . . . . . . . . . . 498
7.7.4 Sample solution . . . . . . . . . . . . . . . . . . . . . . . . 498
7.8 Assignment 8, due Wednesday 2015-04-08, at 11:00pm . . . . . . 498
7.8.1 An ordered set . . . . . . . . . . . . . . . . . . . . . . . . 498
7.8.2 The testOrderedSet wrapper . . . . . . . . . . . . . . . 499
7.8.3 Submitting your assignment . . . . . . . . . . . . . . . . . 500
7.8.4 Sample solution . . . . . . . . . . . . . . . . . . . . . . . . 500
7.9 Assignment 9, due Wednesday 2015-04-15, at 11:00pm . . . . . . 505
7.9.1 Finding a cycle in a maze . . . . . . . . . . . . . . . . . . 505
7.9.2 Input and output format . . . . . . . . . . . . . . . . . . 505
11
7.9.3 Submitting and testing your program . . . . . . . . . . . 507
7.9.4 Sample solution . . . . . . . . . . . . . . . . . . . . . . . . 507
0.1 Overview
This is the course information for CPSC 223: Data Structures and Programming
Techniques for the Spring 2015 semester. This document is available in two
formats, both of which should contain the same information:
• HTML
• PDF
Code examples can be downloaded from links in the text, or can be found in the
examples directory.
The links above point to www.cs.yale.edu. In case this machine is down,
a backup copy of these files can be found at https://www.dropbox.com/sh/
omg9qcxkxeiam2o/AACRAJOTj8af6V7RC1cXBHjQa?dl=0.
This document is a work in progress, and is likely to change frequently as the
semester progresses.
0.1.1 License
0.1.2 Resources
12
• Data structure visualizations. Much better than the ASCII art (at best)
illustrations you will find in this document.1
0.1.3 Documentation
Please feel free to send questions or comments on the class or anything connected
to it to [email protected].
For questions about individual assignments, you may be able to get a faster
response using Piazza. Note that questions you ask there are visible to other
students if not specifically marked private, so be careful about broadcasting your
draft solutions.
me to it.
13
2015-01-14 Arithmetic in C. Readings: Integer constants, Integer operators,
Operator precedence (we didn’t actually do the full operator precedence
table in class, but it’s a nice summary of what operators are available, and
if you don’t like typing parentheses everywhere it’s useful to have an idea
of how precedence and associativity work); K&R §§1.4, 2.2, 2.3, 2.5, 2.6,
2.8, 2.9, and 2.12.
2015-01-16 Local variables and assignment operators. The ++ and -- oper-
ators. More specialized operators: , and ?:. I/O using getchar and
putchar. Control structures: if, switch, while, for. Readings: Vari-
ables, Statements through The for loop; K&R §1.3, 1.5, 2.1, 2.4, and
3.1–3.6.
2015-01-21 Goto-like control structures: break, continue, goto, and
return. Functions. Readings: Rest of [Statements]{#statements},
Functions{#functions}; K&R §3.7, 3.8, 4.1, and 4.5. Examples from
lecture (with a bit of after-the-fact sprucing up) can be found in the
examples directory.
2015-01-26 Start of pointers and arrays: pointer types and pointer variables.
The & and * operators. Using a pointer to get a value out of a function.
Array declarations. Preventing array modification with const. Storage
allocation: malloc, free, and realloc. Readings: Pointers up through
Arrays and functions; K&R §5.1–5.4. Examples.
2015-01-28 More on pointers and arrays: Multi-dimensional arrays, C99
variable-length arrays. Function pointers. Finding storage allocation
bugs using valgrind. Readings: Rest of Pointers, Valgrind; K&R
§§5.6–5.9, 5.11. Examples from lecture: original array-of-pointers-to-arrays
implementation array2dOriginal.c, valgrind-approved version after
removing printArray2D on uninitialized data array2d.c, buggy version
demonstrating how valgrind complains about writing off the end of an
array and doing multiple frees of the same block array2dBad.c. An issue
that came up in lecture is that all of these implementations are a little bit
inefficient in that they allocate a separate block for each row, which means
extra overhead for mallocs data and the possibility that the rows may be
scattered throughout memory, causing issues with virtual memory paging.
Here is yet another implementation that gets space for both the array
of row pointers and all rows with a single call to malloc and then does
pointer arithmetic to slice the space up.2 There is also a generic version of
the simple approach in the section on multidimensional arrays.
2015-02-02 Strings in C: null-terminated strings. What goes wrong if you
forget to put on the null. Various library functions from <string.h> and
how one might implement them. The perils of gets and bounded-size
buffers, and how to use malloc and realloc to avoid them. Meaning of
argv. Readings: Strings; K&R §§5.5, 5.10, B2. Examples from lecture.
2015-02-04 Structured data types: structs, unions, and enums. Type aliases
2 Note that because each row is in the same malloc-ed block as its adjacent rows, valgrind
will not detect if you run off the end of a row in this implementation.
14
using typedef. Opaque struct definitions and separating interface from
implementation. Readings: Structured data types, typedef; K&R Chapter
6, §2.5 (for enums). Examples from lecture, plus a working version of the
intArray implementation together with the originally stubby intArray.c
and the partial version from the end of lecture.
2015-02-09 More C stuff: Makefiles. Floating-point arithmetic and the math
library. Timing code with a profiler. Basics of file I/O. Readings: Make,
Floating point types, Performance tuning, Input and output; K&R §§2.7
and 7.5, Appendix B4. Examples from lecture.
2015-02-11 Start of data structures: efficiency of different data structures,
linked lists. Readings: Asymptotic notation, Linked lists. Examples from
lecture including improved stack.c and working queue.c.
2015-02-16 Invariants and representation functions for abstract data types.
The deque type, with two implementations: a circular doubly-linked list
and a ring buffer. Readings: Abstract data types, deques. Examples from
lecture.
2015-02-18 Hash Wednesday: set and map data types, hash tables. Readings:
Hash tables. Examples from lecture.
2015-02-23 Various C preprocessor tricks: macros with arguments, string pro-
cessing in macros, non-syntactic macros, conditional compilation. Readings:
Macros; K&R Appendix A12.3. Examples from lecture.
2015-02-25 Polymorphism in C: generic containers and object-oriented pro-
gramming (of a sort) using structs full of function pointers. Example of
using git for version control (you will not be tested on version control).
Readings: Generic containers, version control. Examples from lecture.
Unlike the actual example from lecture, this version really works, instead
of just inserting 0 over and over again.
2015-03-02 Recursion. Readings: Recursion. Examples from lecture.
2015-03-04 Exam 1. This took place at the usual class time (1:00–2:15), and
was a closed-book test potentially covering all material discussed in lecture
prior to the exam. Sample exams from previous years: 2005, 2012. Sample
solutions.
2015-03-23 Binary trees and heaps. Readings: Binary trees, Heaps. Examples
from lecture.
2015-03-25 Binary search tree implementation basics: insertion, search, dele-
tion, various kinds of traversals. Readings: Binary search trees. Examples
from lecture.
2015-03-30 Balanced binary search trees: augmented trees and AVL trees. We
also saw a little bit about red-black trees, but not enough to actually be
useful. Readings: Augmented trees, AVL trees. Example from lecture: see
AVL tree implementation.
2015-04-01 Self-adjusting binary search trees: splay trees, a little bit about
scapegoat trees. Readings: Splay trees. There was no new code in lecture
but we did spend a while looking at a pre-prepared splay tree implementa-
tion.
2015-04-06 Graphs: structure of a graph, graph representations, basic ideas of
15
graph search. Readings: Graphs up to start of graph search.
2015-04-08 More graphs: depth-first and breadth-first search. Minimum span-
ning trees and shortest paths. Readings: Rest of graphs. BFS example
from lecture. The program I was using in lecture to make nice pictures of
graphs was dot, specifically dot -Tpng. Thanks to the good folks at ITS,
this is now installed in the Zoo along with the rest of the GraphViz tools.
2015-04-13 Dynamic programming: all-pairs shortest paths, longest increasing
subsequence, longest common subsequence. Readings: Dynamic program-
ming. Examples from lecture.
2015-04-15 Randomized data structures. Readings: Randomization. The
devurandom.c example from lecture.
2015-04-20 Data structures for strings: tries, TSTs, and variants; radix sort.
Readings: String processing.
2015-04-22 Exam 2. This took place at the usual class time (1:00–2:15),
and was a closed-book test potential covering all material discussed in
lecture during the semester. Sample exams from previous years: 2005,
2012. Sample solutions.
Here are some topics that were not covered specifically this semester but can be
found in the notes.
• Iterators
• Suffix arrays
• Testing during development
• Algorithm design techniques
• Bit manipulation
• Persistence
• C++
• What next
0.3 Syllabus
Syllabus for Computer Science 223b, Data Structures and Programming Tech-
niques. Instructor: James Aspnes.
On-line information about the course, including the lecture schedule, lecture
notes, and information about assignments, can be found at http://www.cs.yale.
edu/homes/aspnes/classes/223/notes.html. This document will be updated
frequently during the semester, and is also available in PDF format.
16
0.3.2 Meeting times
Lectures are MW 13:00–14:15 in WLH 201 (Sudler Hall). The lecture schedule
can be found in the course notes. A calendar is also available.
0.3.4 Prerequisites
0.3.5 Textbook
Nine weekly homework assignments, and two in-class exams. Assignments will
be weighted equally in computing the final grade. Each exam will count as three
assignments.
0.3.7 Staff
17
0.3.7.1 Instructor
James Aspnes ([email protected], http://www.cs.yale.edu/homes/
aspnes/). Office: AKW 401. If my open office hours don’t work for you, please
send email to make an appointment.
Students are free to discuss homework problems and course material with each
other, and to consult with the instructor or a TA. Solutions handed in, however,
should be the student’s own work. If a student benefits substantially from
hints or solutions received from fellow students or from outside sources, then
the student should hand in their solution but acknowledge the outside sources,
and we will apportion credit accordingly. Using outside resources in solving a
problem is acceptable but plagiarism is not.
From time to time, ambiguities and errors may creep into homework assignments.
Questions about the interpretation of homework assignments should be sent
to the instructor at [email protected]. Clarifications will appear in the
on-line version of the assignment.
Assignments submitted after the deadline without a Dean’s Excuse are automat-
ically assessed a 2%/hour penalty.
18
0.4 Introduction
There are two purposes to this course: to teach you to program in the C
programming language, and to teach you how to choose, implement, and use
data structures and standard programming techniques.
19
0.4.2 Why should you learn about data structures and programming
techniques?
For small programs, you don’t need much in the way of data structures. But as
soon as you are representing reasonably complicated data, you need some place
to store it. Thinking about how you want to store and organize this data can be
a good framework for organizing the rest of your program.
Many programming environments will give you a rich collection of built-in data
structures as part of their standard library. C does not: unless you use third-
party libraries, any data structure you want in C you will have to build yourself.
For most data structures this will require an understanding of pointers and
storage allocation, mechanisms often hidden in other languages. Understanding
these concepts will give you a deeper understanding of how computers actually
work, and will both let you function in minimalist environments where you don’t
have a lot of support and let you understand what more convenient environments
are doing under their abstraction barriers.
The same applies to the various programming techniques we will discuss in this
class. While some of the issues that come up are specific to C and similar low-
level languages (particular issues involving disciplined management of storage),
some techniques will apply no matter what kinds of programs you are writing
and all will help in understanding what your computer systems are doing even if
some of the details are hidden.
20
1.1 Getting an account
The Zoo is located on the third floor of Arthur K Watson Hall, toward the
front of the building. If you are a Yale student, your ID should get you into the
building and the room. If you are not a student, you will need to get your ID
validated in AKW 008a to get in after hours.
There are several options for remote use of the Zoo. FastX is the most straight-
forward if you want to replicate the Zoo experience elsewhere. I personally tend
to connect using ssh.
These instructions are adapted from Stan Eisenstat’s documentation for CS323.
To use FastX, you will need an installation key. If you are downloading the
Windows or OSX version from the Yale Software Library, this will appear on
the download page. Otherwise, see the instructions in the following section.
21
1. If you are not logged in:
• Press CTRL + ALT + DELETE. A new screen with a Usage Agree-
ment will appear.
• Click “OK”. A new screen with a NetID and Password box will appear.
• Enter your NetID and Password and click “Continue”. Windows will
log you in.
2. Click on the Windows icon in the lower left-hand corner of the screen. A
new box will appear.
3. Mouse over the “Search programs and files” box in the new window and
type “fastx” (but do not hit return). A list of “Programs” will appear.
4. Click on “FastX” under “Programs” to launch FastX. (If a “Licensing”
window appears asking for an activation key, enter the installation key
from the download page, click “OK”, and click “Close” to dismiss the new
window that appears.)
5. If there is no entry named “Zoo” in the FastX window:
• Click on the green + sign in the upper left-hand corner. A new
window will appear.
• Enter “Zoo” in the Name field.
• Enter “node.zoo.cs.yale.edu” in the Host field.
• Do not change the Port or User field.
• Click “Save” to save the configuration.
6. Double click on the “Zoo” entry. A “Login” box should appear. If a
“Password” box appears instead:
• Click “Cancel”.
• Click on the green pencil in the upper left-hand corner of the FastX
window.
• Delete the contents of the User field. A grayed out “Joe” will appear.
• Click “Save” to save the configuration.
• Double click on the “Zoo” entry again. A “Login” box will appear.
7. Enter your Yale netID in the “Login” box (it should already be there) and
click “Continue”. (If a warning appears asking whether you want to accept
a new key, click on “Accept” to dismiss it.) A “Password” box will appear.
8. Enter your password in the “Password” box and click on “Continue”. A
new “Start new session” entry will appear in the right-hand side of the
FastX window.
9. Click on “Start new session” to produce a pulldown menu and click on
either “Gnome” or “KDE” to choose a window manager (Gnome is the
default in the Zoo) or “Xterm” to open a terminal window.
WARNING: If you click on “Gnome” but the desktop that appears does
not have the usual “Applications” and “Places” in the upper left-hand
corner, then:
1. Type ALT-F2 (that is, press the ALT and F2 keys simultaneously) to
open a command field.
2. Enter the command “gnome-shell –mode=classic -r” (without the
surrounding quotes) and press the “Enter” key.
10. A new window with a Zoo Linux desktop should open. You may resize it
22
by dragging on the lower left-hand corner if you prefer a different size.
11. When you log out of the Linux desktop, close the “FastX” window by
clicking the red X in the upper right-hand corner.
12. Do not forget to log out of Windows when you are done.
23
2. Enter the command “gnome-shell –mode=classic -r” (without the
surrounding quotes) and press the “Enter” key.
5. A new window with a Zoo Linux desktop should open. You may resize it
by dragging on the lower left-hand corner if you prefer a different size.
6. When you log out of the Linux desktop, close the “FastX” window by
clicking the red X in the upper right-hand corner.
24
3. Enter the password for your Yale netID and click “OK”. A “Start a new
session” entry will appear in the FastX window.
4. Click on “Start new session” to produce a pulldown menu and click on
either “Gnome” or “KDE” to choose a window manager (Gnome is the
default in the Zoo) or “Xterm” to open a terminal window.
WARNING: If you click on “Gnome” but the desktop that appears does
not have the usual “Applications” and “Places” in the upper left-hand
corner, then:
1. Type ALT-F2 (that is, press the ALT and F2 keys simultaneously) to
open a command field.
2. Enter the command “gnome-shell –mode=classic -r” (without the
surrounding quotes) and press the “Enter” key.
5. A new window with a Zoo Linux desktop should open behind the FastX
window. You may resize it by dragging on the lower left-hand corner if
you prefer a different size.
6. When you log out of the Linux desktop, close the “FastX” window by
clicking the red dot in the upper left-hand corner.
Hello all,
I've been asked to write up a quick guide on how to access the Linux
computers in the Zoo. For those who need this information, please read
on.
There are 2 ways of accessing the Zoo nodes, by walking up to one and
logging in on the console (the computers are located on the 3rd floor of
AKW), or by connecting remotely via SSH. Telnet access is not allowed.
SSH clients for various operating systems are available here:
http://www.yale.edu/software/
Mac OSX comes with an SSH client by default. A good choice for an SSH
client if you run Microsoft Windows is PuTTY:
http://www.chiark.greenend.org.uk/~sgtatham/putty/
With the exception of a few legacy accounts, the Zoo uses your campus-wide
NetID and password for login access. However, you must sign up for a Zoo
account before access is allowed. To sign up for a Zoo account, go to
25
this web page:
http://zoo.cs.yale.edu/accounts.html
Then login with your campus-wide NetID and password. You may choose a
different shell, or set up your account to be enrolled in a class if that
is appropriate for you, but neither is necessary. Just click "Submit".
Within an hour, your Zoo account will be created, and you will receive
more information via e-mail about how to access the Zoo.
Users cannot log into zoo.cs.yale.edu (the central file server) directly,
they must log into one of the Zoo nodes. Following is the list of Zoo
nodes:
aphid.zoo.cs.yale.edu lion.zoo.cs.yale.edu
bumblebee.zoo.cs.yale.edu macaw.zoo.cs.yale.edu
cardinal.zoo.cs.yale.edu monkey.zoo.cs.yale.edu
chameleon.zoo.cs.yale.edu newt.zoo.cs.yale.edu
cicada.zoo.cs.yale.edu peacock.zoo.cs.yale.edu
cobra.zoo.cs.yale.edu perch.zoo.cs.yale.edu
cricket.zoo.cs.yale.edu python.zoo.cs.yale.edu
frog.zoo.cs.yale.edu rattlesnake.zoo.cs.yale.edu
gator.zoo.cs.yale.edu rhino.zoo.cs.yale.edu
giraffe.zoo.cs.yale.edu scorpion.zoo.cs.yale.edu
grizzly.zoo.cs.yale.edu swan.zoo.cs.yale.edu
hare.zoo.cs.yale.edu termite.zoo.cs.yale.edu
hippo.zoo.cs.yale.edu tick.zoo.cs.yale.edu
hornet.zoo.cs.yale.edu tiger.zoo.cs.yale.edu
jaguar.zoo.cs.yale.edu tucan.zoo.cs.yale.edu
koala.zoo.cs.yale.edu turtle.zoo.cs.yale.edu
ladybug.zoo.cs.yale.edu viper.zoo.cs.yale.edu
leopard.zoo.cs.yale.edu zebra.zoo.cs.yale.edu
If you have already created an account, you can SSH directly to one of
the above computers and log in with your campus-wide NetID and
password. You can also SSH to node.zoo.cs.yale.edu, which will connect
you to a random Zoo node.
Feel free to contact me if you have any questions about the Zoo.
thanks,
Jim Faulkner
Zoo Systems Administrator
26
1.3.3 GUI access
27
1.4 How to compile and run programs
See the chapter on how to use the Zoo for details of particular commands. The
basic steps are
• Creating the program with a text editor of your choosing. (I like vim for
long programs and cat for very short ones.)
• Compiling it with gcc.
• Running it.
If any of these steps fail, the next step is debugging. We’ll talk about debugging
elsewhere.
Use your favorite text editor. The program file should have a name of the form
foo.c; the .c at the end tells the C compiler the contents are C source code.
Here is a typical C program:
#include <stdio.h>
int
main(int argc, char **argv)
{
int i;
return 0;
}
examples/count.c
28
3
4
5
6
7
8
9
10
$
The first line is the command to compile the program. The dollar sign is my
prompt, which is printed by the system to tell me it is waiting for a command.
The command calls gcc as c99 with arguments -g3 (enable maximum debugging
info), -o (specify executable file name, otherwise defaults to a.out), count (the
actual executable file name), and count.c (the source file to compile). This
tells gcc that we should compile count.c to count in C99 mode with maximum
debugging info included in the executable file.
The second line runs the output file count. Calling it ./count is necessary
because by default the shell (the program that interprets what you type) only
looks for programs in certain standard system directories. To make it run a
program in the current directory, we have to include the directory name.
29
of the arguments (essentially all the words on the command line, including
the program name). Note that it would also work to do this as one line
(as K&R typically does); the C compiler doesn’t care about whitespace,
so you can format things however you like, subject to the constraint that
consistency will make it easier for people to read your code.
• Everything inside the curly braces is the body of the main function. This
includes
– The declaration int i;, which says that i will be a variable that
holds an int (see the chapter on Integer Types).
– Line 10, which prints an informative message using puts (discussed
in the chapter on input and output.
– The for loop on Lines 11–13, which executes its body for each value
of i from 1 to 10. We’ll explain how for loops work later. Note that
the body of the loop is enclosed in curly braces just like the body
of the main function. The only statement in the body is the call to
printf on Line 12; this includes a format string that specifies that
we want a decimal-formatted integer followed by a newline (the \n).
– The return 0; on Line 15 tells the operating system that the pro-
gram worked (the convention in Unix is that 0 means success). If
the program didn’t work for some reason, we could have returned
something else to signal an error.
When you sign up for an account in the Zoo, you are offered a choice of possible
shell programs. The examples below assume you have chosen bash, the Bourne-
again shell written by the GNU project. Other shells behave similarly for basic
commands.
When you log in to a Zoo node directly, you may not automatically get a shell
window. If you use the default login environment (which puts you into the KDE
30
window manager), you need to click on the picture of the display with a shell in
from of it in the toolbar at the bottom of the screen. If you run Gnome instead
(you can change your startup environment using the popup menu in the login
box), you can click on the foot in the middle of the toolbar. Either approach will
pop up a terminal emulator from which you can run emacs, gcc, and so forth.
The default login shell in the Zoo is bash, and all examples of shell command
lines given in these notes will assume bash. You can choose a different login
shell on the account sign-up page if you want to, but you are probably best off
just learning to like bash.
Most of what one does with Unix programs is manipulate the filesystem.
Unix files are unstructured blobs of data whose names are given by paths
consisting of a sequence of directory names separated by slashes: for exam-
ple /home/accts/some-user/cs223/hw1.c. At any time you are in a current
working directory (type pwd to find out what it is and cd new-directory to
change it). You can specify a file below the current working directory by
giving just the last part of the pathname. The special directory names .
and .. can also be used to refer to the current directory and its parent. So
/home/accts/some-user/cs223/hw1.c is just hw1.c or ./hw1.c if your current
working directory is /home/accts/some-user/cs223, cs223/hw1.c if your cur-
rent working directory is /home/accts/some-user, and ../cs223/hw1.c if your
current working directory is /home/accts/some-user/illegal-downloads.
All Zoo machines share a common filesystem, so any files you create or change
on one Zoo machine will show up in the same place on all the others.
31
ls ls lists all the files in the current directory. Some useful variants:
• ls /some/other/dir; list files in that directory instead.
• ls -l; long output format showing modification dates and owners.
mkdir mkdir dir will create a new directory in the current directory named
dir.
rmdir rmdir dir deletes a directory. It only works on directories that contain
no files.
cd cd dir changes the current working directory. With no arguments, cd
changes back to your home directory.
pwd pwd (“print working directory”) shows what your current directory is.
mv mv old-name new-name changes the name of a file. You can also use this
to move files between directories.
cp cp old-name new-name makes a copy of a file.
rm rm file deletes a file. Deleted files cannot be recovered. Use this command
carefully.
chmod chmod changes the permissions on a file or directory. See the man page
for the full details of how this works. Here are some common chmod’s:
• chmod 644 file; owner can read or write the file, others can only
read it.
• chmod 600 file; owner can read or write the file, others can’t do
anything with it.
• chmod 755 file; owner can read, write, or execute the file, others
can read or execute it. This is typically used for programs or for
directories (where the execute bit has the special meaning of letting
somebody find files in the directory).
• chmod 700 file; owner can read, write, or execute the file, others
can’t do anything with it.
emacs, gcc, make, gdb, git See corresponding sections.
Sometimes you may have a running program that won’t die. Aside from costing
you the use of your terminal window, this may be annoying to other Zoo users,
especially if the process won’t die even if you close the terminal window or log
out.
There are various control-key combinations you can type at a terminal window
to interrupt or stop a running program.
32
ctrl-C Interrupt the process. Many processes (including any program you write
unless you trap SIGINT using the sigaction system call) will die instantly
when you do this. Some won’t.
ctrl-Z Suspend the process. This will leave a stopped process lying around.
Type jobs to list all your stopped processes, fg to restart the last process
(or fg %1 to start process %1 etc.), bg to keep running the stopped process
in the background, kill %1 to kill process %1 politely, kill -KILL %1 to
kill process %1 whether it wants to die or not.
ctrl-D Send end-of-file to the process. Useful if you are typing test input
to a process that expects to get EOF eventually or writing programs
using cat > program.c (not really recommmended). For test input,
you are often better putting it into a file and using input redirection
(./program < test-input-file); this way you can redo the test after
you fix the bugs it reveals.
ctrl-\ Quit the process. Sends a SIGQUIT, which asks a process to quit and
dump core. Mostly useful if ctrl-C and ctrl-Z don’t work.
If you have a runaway process that you can’t get rid of otherwise, you can use
ps g to get a list of all your processes and their process ids. The kill command
can then be used on the offending process, e.g. kill -KILL 6666 if your evil
process has process id 6666. Sometimes the killall command can simplify
this procedure, e.g. killall -KILL evil kills all process with command name
evil.
If you compile your own program, you will need to prefix it with ./ on the
command line to tell the shell that you want to run a program in the current
directory (called ‘.’) instead of one of the standard system directories. So for
example, if I’ve just built a program called count, I can run it by typing
$ ./count
Here the “$ ” is standing in for whatever your prompt looks like; you should
not type it.
Any words after the program name (separated by whitespace—spaces and/or
tabs) are passed in as arguments to the program. Sometimes you may wish to
pass more than one word as a single argument. You can do so by wrapping the
argument in single quotes, as in
$ ./count 'this is the first argument' 'this is the second argument'
Some programs take input from standard input (typically the terminal). If
you are doing a lot of testing, you will quickly become tired of typing test input
33
at your program. You can tell the shell to redirect standard input from a file
by putting the file name after a < symbol, like this:
$ ./count < huge-input-file
A ‘>’ symbol is used to redirect standard output, in case you don’t want to
read it as it flies by on your screen:
$ ./count < huge-input-file > huger-output-file
A useful file for both input and output is the special file /dev/null. As input,
it looks like an empty file. As output, it eats any characters sent to it:
$ ./sensory-deprivation-experiment < /dev/null > /dev/null
You can also pipe programs together, connecting the output of one to the input
of the next. Good programs to put at the end of a pipe are head (eats all but the
first ten lines), tail (eats all but the last ten lines), more (lets you page through
the output by hitting the space bar, and tee (shows you the output but also saves
a copy to a file). A typical command might be something like ./spew | more or
./slow-but-boring | tee boring-output. Pipes can consist of a long train
of programs, each of which processes the output of the previous one and supplies
the input to the next. A typical case might be:
$ ./do-many-experiments | sort | uniq -c | sort -nr
which, if ./do-many-experiments gives the output of one experiment on each
line, produces a list of distinct experimental outputs sorted by decreasing fre-
quency. Pipes like this can often substitute for hours of real programming.
To write your programs, you will need to use a text editor, preferably one that
knows enough about C to provide tools like automatic indentation and syntax
highlighting. There are three reasonable choices for this in the Zoo: kate, emacs,
and vim (which can also be run as vi). Kate is a GUI-style editor that comes
with the KDE window system; it plays nicely with the mouse, but Kate skills will
not translate well into other environements. Emacs and Vi have been the two
contenders for the One True Editor since the 1970s—if you learn one (or both)
you will be able to use the resulting skills everywhere. My personal preference is
to use Vi, but Emacs has the advantage of using the same editing commands as
the shell and gdb command-line interfaces.
To start Emacs, type emacs at the command line. If you are actually sitting at
a Zoo node it should put up a new window. If not, Emacs will take over the
current window. If you have never used Emacs before, you should immediately
34
type C-h t (this means hold down the Control key, type h, then type t without
holding down the Control key). This will pop you into the Emacs built-in
tutorial.
35
2.2.2 Using Vi instead of Emacs
If you don’t find yourself liking Emacs very much, you might want to try Vim
instead. Vim is a vastly enhanced reimplementation of the classic vi editor,
which I personally find easier to use than Emacs. Type vimtutor to run the
tutorial.
One annoying feature of Vim is that it is hard to figure out how to quit. If you
don’t mind losing all of your changes, you can always get out by hitting the
Escape key a few times and then typing ~ \\\ :qa!\\\ ~
To run Vim, type vim or vim filename from the command line. Or you can use
the graphical version gvim, which pops up its own window.
Vim is a modal editor, meaning that at any time you are in one of several modes
(normal mode, insert mode, replace mode, operator-pending mode, etc.), and
the interpretation of keystrokes depends on which mode you are in. So typing
jjjj in normal mode moves the cursor down four lines, while typing jjjj in
insert mode inserts the string jjjj at the current position. Most of the time
you will be in either normal mode or insert mode. There is also a command
mode entered by hitting : that lets you type longer commands, similar to the
Unix command-line or M-x in Emacs.
36
Edit a different file.
:q Quit. Vi will refuse to do this if you have unwritten files. See :wa for how
to fix this, or use :q! if you want to throw away your changes and quit
anyway. The shortcuts :x and :wq do a write of the current file followed
by quitting.
h, j, k, l Move the cursor left, down, up, or right. You can also use the arrow
keys (in both normal mode and insert mode).
x Delete the current character.
D Delete to end of line.
dd Delete all of the current line. This is a special case of a more general d
command. If you precede it with a number, you can delete multiple lines:
5dd deletes the next 5 lines. If you replace the second d with a motion
command, you delete until wherever you land: d$ deletes to end of line
(D is faster), dj deletes this line and the line after it, d% deletes the next
matching group of parantheses/braces/brackets and whatever is between
them, dG deletes to end of file—there are many possibilities. All of these
save what you deleted into register "" so you can get them back with p.
yy Like dd, but only saves the line to register "" and doesn’t delete it. (Think
copy). All the variants of dd work with yy: 5yy, y$, yj, y%, etc.
p Pull whatever is in register "". (Think paste).
<< and >> Outdent or indent the current line one tab stop.
:make Run make in the current directory. You can also give it arguments, e.g.,
:make myprog, :make test. Use :cn to go to the next error if you get
errors.
:! Run a command, e.g., :! echo hello world or :! gdb myprogram. Returns
to Vim when the command exits (control-C can sometimes be helpful if
your command isn’t exiting when it should). This works best if you ran
Vim from a shell window; it doesn’t work very well if Vim is running in its
own window.
37
ESC Get out of insert mode!
2.2.2.2 Settings
Unlike Emacs, Vim’s default settings are not very good for editing C programs.
You can fix this by creating a file called .vimrc in your home directory with the
following commands:
set shiftwidth=4
set autoindent
set backup
set cindent
set hlsearch
set incsearch
set showmatch
set number
syntax on
filetype plugin on
filetype indent on
examples/sample.vimrc
(You can download this file by clicking on the link.)
In Vim, you can type e.g. :help backup to find out what each setting does.
Note that because .vimrc starts with a ., it won’t be visible to ls unless you
use ls -a or ls -A.
A C program will typically consist of one or more files whose names end with .c.
To compile foo.c, you can type gcc foo.c. Assuming foo.c contains no errors
egregious enough to be detected by the extremely forgiving C compiler, this will
produce a file named a.out that you can then execute by typing ./a.out.
If you want to debug your program using gdb or give it a different name,
you will need to use a longer command line. Here’s one that compiles foo.c
to foo (run it using ./foo) and includes the information that gdb needs:
gcc -g3 -o foo foo.c
If you want to use C99 features, you will need to tell gcc to use C99 instead
of its own default dialect of C. You can do this either by adding the argument
-std=c99 as in gcc -std=c99 -o foo foo.c or by calling gcc as c99 as in c99
-o foo foo.c.
38
By default, gcc doesn’t check everything that might be wrong with your program.
But if you give it a few extra arguments, it will warn you about many (but not
all) potential problems: c99 -g3 -Wall -pedantic -o foo foo.c.
2.3.2 Make
For complicated programs involving multiple source files, you are probably better
off using make than calling gcc directly. Make is a “rule-based expert system”
that figures out how to compile programs given a little bit of information about
their components.
For example, if you have a file called foo.c, try typing make foo and see what
happens.
In general you will probably want to write a Makefile, which is named Makefile
or makefile and tells make how to compile programs in the same directory. Here’s
a typical Makefile:
# Any line that starts with a sharp is a comment and is ignored
# by Make.
39
Figure 6: DFS tree
329
Figure 7: BFS tree
330
* struct searchInfo *s;
* int n;
*
* s = searchInfoCreate(g);
*
* n = graph_vertices(g);
* for(i = 0; i < n; i++) {
* dfs(s, i);
* }
*
* ... use results in s ...
*
* searchInfoDestroy(s);
*
*/
struct searchInfo {
Graph graph;
int reached; /* count of reached nodes */
int *preorder; /* list of nodes in order first reached */
int *time; /* time[i] == position of node i in preorder list */
int *parent; /* parent in DFS or BFS forest */
int *depth; /* distance from root */
};
331
#include <assert.h>
#include "graph.h"
#include "genericSearch.h"
a = malloc(sizeof(*a) * n);
assert(a);
return a;
}
s = malloc(sizeof(*s));
assert(s);
s->graph = g;
s->reached = 0;
n = graphVertexCount(g);
s->preorder = createEmptyArray(n);
s->time = createEmptyArray(n);
s->parent = createEmptyArray(n);
s->depth = createEmptyArray(n);
return s;
}
332
/* free searchInfo data---does NOT free graph pointer */
void
searchInfoDestroy(struct searchInfo *s)
{
free(s->depth);
free(s->parent);
free(s->time);
free(s->preorder);
free(s);
}
/* stack/queue */
struct queue {
struct edge *e;
int bottom;
int top;
};
static void
pushEdge(Graph g, int u, int v, void *data)
{
struct queue *q;
q = data;
q->e[q->top].u = u;
q->e[q->top].v = v;
q->top++;
}
333
/* edge we are working on */
struct edge cur;
q.bottom = q.top = 0;
/* no */
assert(r->reached < graphVertexCount(r->graph));
r->parent[cur.v] = cur.u;
r->time[cur.v] = r->reached;
r->preorder[r->reached++] = cur.v;
if(cur.u == cur.v) {
/* we could avoid this if we were certain SEARCH_INFO_NULL */
/* would never be anything but -1 */
r->depth[cur.v] = 0;
} else {
r->depth[cur.v] = r->depth[cur.u] + 1;
}
free(q.e);
}
void
334
dfs(struct searchInfo *results, int root)
{
genericSearch(results, root, 0);
}
void
bfs(struct searchInfo *results, int root)
{
genericSearch(results, root, 1);
}
examples/graphs/genericSearch.c
And here is some test code: genericSearchTest.c. You will need to compile
genericSearchTest.c together with both genericSearch.c and graph.c to
get it to work. This Makefile will do this for you.
335
There are two parts to dynamic programming. The first part is a programming
technique: dynamic programming is essentially divide and conquer run in reverse:
we solve a big instance of a problem by breaking it up recursively into smaller
instances; but instead of carrying out the computation recursively from the top
down, we start from the bottom with the smallest instances of the problem,
solving each increasingly large instance in turn and storing the result in a
table. The second part is a design principle: in building up our table, we are
careful always to preserve alternative solutions we may need later, by delaying
commitment to particular choices to the extent that we can.
The bottom-up aspect of dynamic programming is most useful when a straight-
forward recursion would produce many duplicate subproblems. It is most efficient
when we can enumerate a class of subproblems that doesn’t include too many
extraneous cases that we don’t need for our original problem.
To take a simple example, suppose that we want to compute the n-th Fibonacci
number using the defining recurrence
• F (n) = F (n − 1) + F (n − 2)
• F (1) = F (0) = 1.
A naive approach would simply code the recurrence up directly:
int
fib(int n)
{
if(n < 2) {
return 1
} else {
return fib(n-1) + fib(n-2);
}
}
The running time of this procedure is easy to compute. The recurrence is
• T (n) = T (n − 1) + T (n − 2) + Θ(1),
whose solution is Θ(an ) where a is the golden ratio 1.6180339887498948482 . . ..
This is badly exponential.23
4.13.1 Memoization
The problem is that we keep recomputing values of fib that we’ve already
computed. We can avoid this by memoization, where we wrap our recursive
solution in a memoizer that stores previously-computed solutions in a hash
23 But it’s linear in the numerical value of the output, which means that fib(n) will actually
terminate in a reasonable amount of time on a typical modern computer when run on any n
small enough that F (n) fits in 32 bits. Running it using 64-bit (or larger) integer representations
will be slower.
336
table. Sensible programming languages will let you write a memoizer once and
apply it to arbitrary recursive functions. In less sensible programming languages
it is usually easier just to embed the memoization in the function definition itself,
like this:
int
memoFib(int n)
{
int ret;
if(hashContains(FibHash, n)) {
return hashGet(FibHash, n);
} else {
ret = memoFib(n-1) + memoFib(n-2);
hashPut(FibHash, n, ret);
return ret;
}
}
The assumption here is that FibHash is a global hash table that we have initialized
to map 0 and 1 to 1. The total cost of running this procedure is O(n), because
fib is called at most twice for each value k in 0 . . . n.
Memoization is a very useful technique in practice, but it is not popular with
algorithm designers because computing the running time of a complex memoized
procedure is often much more difficult than computing the time to fill a nice
clean table. The use of a hash table instead of an array may also add overhead
(and code complexity) that comes out in the constant factors. But it is always
the case that a memoized recursive procedure considers no more subproblems
than a table-based solution, and it may consider many fewer if we are sloppy
about what we put in our table (perhaps because we can’t easily predict what
subproblems will be useful).
Dynamic programming comes to the rescue. Because we know what smaller cases
we have to reduce F(n) to, instead of computing F(n) top-down, we compute it
bottom-up, hitting all possible smaller cases and storing the results in an array:
int
fib2(int n)
{
int *a;
int i;
int ret;
if(n < 2) {
337
return 1;
} else {
a = malloc(sizeof(*a) * (n+1));
assert(a);
a[1] = a[2] = 1;
ret = a[n];
free(a);
return ret;
}
Notice the recurrence is exactly the same in this version as in our original
recursive version, except that instead of computing F(n-1) and F(n-2) recursively,
we just pull them out of the array. This is typical of dynamic-programming
solutions: often the most tedious editing step in converting a recursive algorithm
to dynamic programming is changing parentheses to square brackets. As with
memoization, the effect of this conversion is dramatic; what used to be an
exponential-time algorithm is now linear-time.
338
This last step requires some explanation. We don’t really want to store in
table[i] the full longest increasing subsequence ending at position i, because it
may be very big. Instead, we store the index of the second-to-last element of this
sequence. Since that second-to-last element also has a table entry that stores the
index of its predecessor, by following the indices we can generate a subsequence
of length O(n), even though we only stored O(1) pieces of information in each
table entry. This is similar to the parent pointer technique used in graph search
algorithms.
Here’s what the code looks like:
/* compute a longest strictly increasing subsequence of an array of ints */
/* input is array a with given length n */
/* returns length of LIS */
/* If the output pointer is non-null, writes LIS to output pointer. */
/* Caller should provide at least sizeof(int)*n space for output */
/* If there are multiple LIS's, which one is returned is arbitrary. */
unsigned long
longest_increasing_subsequence(const int a[], unsigned long n, int *output);
examples/dynamicProgramming/lis/lis.h
#include <stdlib.h>
#include <assert.h>
#include "lis.h"
unsigned long
longest_increasing_subsequence(const int a[], unsigned long n, int *output)
{
struct lis_data {
unsigned long length; /* length of LIS ending at this point */
unsigned long prev; /* previous entry in the LIS ending at this point
} *table;
unsigned long i;
unsigned long j;
unsigned long best_length;
339
/* default best is just this element by itself */
table[i].length = 1;
table[i].prev = n; /* default end-of-list value */
output[best_length - i - 1] = a[scan];
scan = table[scan].prev;
}
}
free(table);
return best_length;
}
340
examples/dynamicProgramming/lis/lis.c
A sample program that runs longest_increasing_subsequence on a list of
numbers passed in by stdin is given in test_lis.c. Here is a Makefile.
Implemented like this, the cost of finding an LIS is O(n2 ), because to compute
each entry in the array, we have to search through all the previous entries to
find the longest path that ends at a value less than the current one. This can be
improved by using a more clever data structure. If we use a binary search tree
that stores path keyed by the last value, and augment each node with a field
that represents the maximum length of any path in the subtree under that node,
then we can find the longest feasible path that we can append the current node
to in O(log n) time instead of O(n) time. This brings the total cost down to
only O(n log n).
341
endpoints i and j, which can be anything). When k = 0, this is just the length
of the i–j edge, or +∞ if there is no such edge. So we can start by computing
L(i, j, 0) for all i. Now given L(i, j, k) for all i and some k, we can compute
L(i, j, k + 1) by observing that any shortest i–j path that has intermediate
vertices in 0 . . . k either consists of a path with intermediate vertices in 0 . . . k − 1,
or consists of a path from i to k followed by a path from k to j, where both of
these paths have intermediate vertices in 0 . . . k − 1. So we get
• L(i, j, k + 1) = min(L(i, j, k), L(i, k, k) + L(k, j, k).
Since this takes O(1) time to compute if we have previously computed L(i, j, k)
for all i and j, we can fill in the entire table in O(n3 ) time.
Implementation details:
• If we want to reconstruct the shortest path in addition to computing its
length, we can store the first vertex for each i–j path. This will either be
(a) the first vertex in the i–j path for the previous k, or (b) the first vertex
in the i–k path.
• We don’t actually need to use a full three-dimensional array. It’s enough
to store one value for each pair i, j and let k be implicit. At each step we
let L[i][j] be min(L[i][j], L[i][k] + L[k][j]). The trick is that we don’t care
if L[i][k] or L[k][j] has already been updated, because that will only give
us paths with a few extra k vertices, which won’t be the shortest paths
anyway assuming no negative cycles.
342
x and y are strings. Let a and b be single characters. Then L(xa, yb) is the
maximum of:
• L(x, y) + 1, if a = b,
• L(xa, y), or
• L(x, yb).
The idea is that we either have a new matching character we couldn’t use before
(the first case), or we have an LCS that doesn’t use one of a or b (the remaining
cases). In each case the recursive call to LCS involves a shorter prefix of xa or
yb, with an ultimate base case L(x, y) = 0 if at least one of x or y is the empty
string. So we can fill in these values in a table, as long as we are careful to
make sure that the shorter prefixes are always filled first. If we are smart about
remembering which case applies at each step, we can even go back and extract
an actual LCS, by stitching together to places where a = b. Here’s a short C
program that does this:
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
#include <string.h>
#include <limits.h>
xLen = strlen(x);
yLen = strlen(y);
343
for(i = 0; i < xLen; i++) {
for(j = 0; j < yLen; j++) {
/* we can always do no common substring */
best[i][j].length = 0;
best[i][j].prev = 0;
best[i][j].newChar = 0;
}
}
outPos = best[xLen-1][yLen-1].length;
lcs[outPos--] = '\0';
344
if(p->newChar) {
assert(outPos >= 0);
lcs[outPos--] = p->newChar;
}
}
}
int
main(int argc, char **argv)
{
if(argc != 3) {
fprintf(stderr, "Usage: %s string1 string2\n", argv[0]);
return 1;
}
puts(output);
return 0;
}
examples/dynamicProgramming/lcs/lcs.c
The whole thing takes O(nm) time where n and m are the lengths of A and B.
4.14 Randomization
If you want random values in a C program, there are three typical ways of getting
them, depending on how good (i.e. uniform, uncorrelated, and unpredictable)
you want them to be.
345
E.g.
#include <stdio.h>
#include <stdlib.h>
int
main(int argc, char **argv)
{
printf("%d\n", rand());
return 0;
}
examples/randomization/randOnce.c
The rand function, declared in stdlib.h, returns a random-looking integer in
the range 0 to RAND_MAX (inclusive) every time you call it. On machines using
the GNU C library RAND_MAX is equal to INT_MAX which is typically 23 1 − 1, but
RAND_MAX may be as small as 32767. There are no particularly strong guarantees
about the quality of random numbers that rand returns, but it should be good
enough for casual use, and it has the advantage that as part of the C standard
you can assume it is present almost everywhere.
Note that rand is a pseudorandom number generator: the sequence of values
it returns is predictable if you know its starting state (and is still predictable
from past values in the sequence even if you don’t know the starting state, if
you are clever enough). It is also the case that the initial seed is fixed, so that
the program above will print the same value every time you run it.
This is a feature: it permits debugging randomized programs. As John von
Neumann, who proposed pseudorandom number generators in his 1946 talk
“Various Techniques Used in Connection With Random Digits,” explained:
We see then that we could build a physical instrument to feed random
digits directly into a high-speed computing machine and could have
the control call for these numbers as needed. The real objection
to this procedure is the practical need for checking computations.
If we suspect that a calculation is wrong, almost any reasonable
check involves repeating something done before. At that point the
introduction of new random numbers would be intolerable.
346
int
main(int argc, char **argv)
{
srand(time(0));
printf("%d\n", rand());
return 0;
}
examples/randomization/srandFromTime.c
Here time(0) returns the number of seconds since the epoch (00:00:00 UTC,
January 1, 1970, for POSIX systems, not counting leap seconds). Note that this
still might give repeated values if you run it twice in the same second, and it’s
extremely dangerous if you expect to distribute your code to a lot of people who
want different results, since two of your users are likely to run it twice in the
same second. See the discussion of /dev/urandom below for a better method.
int
main(int argc, char **argv)
{
unsigned int randval;
347
FILE *f;
f = fopen("/dev/random", "r");
fread(&randval, sizeof(randval), 1, f);
fclose(f);
printf("%u\n", randval);
return 0;
}
examples/randomization/devRandom.c
(A similar construction can also be used to obtain a better initial seed for srand
than time(0).)
Both /dev/random and /dev/urandom derive their random bits from physically
random properties of the computer, like time between keystrokes or small
variations in hard disk rotation speeds. The difference between the two is that
/dev/urandom will always give you some random-looking bits, even if it has to
generate extra ones using a cryptographic pseudo-random number generator,
while /dev/random will only give you bits that it is confident are in fact random.
Since your computer only generates a small number of genuinely random bits per
second, this may mean that /dev/random will exhaust its pool if read too often.
In this case, a read on /dev/random will block (just like reading a terminal with
no input on it) until the pool has filled up again.
Neither /dev/random nor /dev/urandom is known to be secure against a deter-
mined attacker, but they are about the best you can do without resorting to
specialized hardware.
348
The problem here is that there are 23 1 outputs from rand, and 6 doesn’t divide
23 1. So 1 and 2 are slightly more likely to come up than 3, 4, 5, or 6. This can
be particularly noticeable if we want a uniform variable from a larger range, e.g.
[0 . . . b(2/3) · 23 1c].
We can avoid this with a technique called rejection sampling, where we reject
excess parts of the output range of rand. For rolling a die, the trick is to reject
anything in the last extra bit of the range that is left over after the largest
multiple of the die size. Here’s a routine that does this, returning a uniform
value in the range 0 to n-1 for any positive n, together with a program that
demonstrates its use for rolling dice:
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
#include <time.h>
return r % n;
}
int
main(int argc, char **argv)
{
int i;
srand(time(0));
putchar('\n');
return 0;
}
349
examples/randomization/randRange.c
More generally, rejection sampling can be used to get random values with
particular properties, where it’s hard to generate a value with that property
directly. Here’s a program that generates random primes:
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
#include <time.h>
/* return 1 if n is prime */
int
isprime(int n)
{
int i;
if(n % 2 == 0 || n == 1) { return 0; }
return 1;
}
return r;
}
int
main(int argc, char **argv)
{
int i;
srand(time(0));
350
}
return 0;
}
examples/randomization/randPrime.c
One temptation to avoid is to re-use your random values. If, for example, you
try to find a random prime by picking a random x and trying x, x+1, x+2, etc.,
until you hit a prime, some primes are more likely to come up than others.
return r;
}
This will find a winning value in 8 tries on average. In contrast, this deterministic
version will take a lot longer for nonzero patterns:
int
matchBitsDeterministic(int pattern)
351
{
int i;
return i;
}
The downside of the randomized approach is that it’s hard to tell when to quit
if there are no matches; if we stop after some fixed number of trials, we get a
Monte Carlo algorithm that may give the wrong answer with small probability.
The usual solution is to either accept a small probability of failure, or interleave
a deterministic backup algorithm that always works. The latter approach gives
a Las Vegas algorithm whose running time is variable but whose correctness is
not.
but it’s not hard to show that on average even the bigger pile has no more than 3/4 of the
elements.
352
* Returns number of elements <= pivot */
static int
splitByPivot(int n, int *a, int pivot)
{
int lo;
int hi;
int temp; /* for swapping */
return lo;
}
if(n == 1) {
return a[0];
}
/* else */
353
pivot = a[rand() % n]; /* we will tolerate non-uniformity */
lo = splitByPivot(n, a, pivot);
if(n <= 1) {
return;
}
/* else */
pivot = a[rand() % n]; /* we will tolerate non-uniformity */
lo = splitByPivot(n, a, pivot);
quickSort(lo, a);
quickSort(n - lo, a + lo);
}
/* shuffle an array */
void
shuffle(int n, int *a)
{
int i;
int r;
int temp;
354
}
}
#define N (1024)
int
main(int argc, char **argv)
{
int a[N];
int i;
shuffle(N, a);
shuffle(N, a);
quickSort(N, a);
return 0;
}
examples/randomization/quick.c
355
the same expected search cost as in a balanced binary tree.
The problem with this approach is that we don’t have any guarantees that the
input will be supplied in random order, and in the worst case we end up with a
linked list. The solution is to put the randomization into the algorithm itself,
making the structure of the tree depend on random choices made by the program
itself.
356
#include "skiplist.h"
struct skiplist {
int key;
int height; /* number of next pointers */
struct skiplist *next[1]; /* first of many */
};
return i;
}
assert(s);
s->key = key;
s->height = height;
return s;
}
357
Skiplist s;
int i;
return s;
}
/* free a skiplist */
void
skiplistDestroy(Skiplist s)
{
Skiplist next;
while(s) {
next = s->next[0];
free(s);
s = next;
}
}
return s->key;
}
358
void
skiplistInsert(Skiplist s, int key)
{
int level;
Skiplist elt;
assert(elt);
359
target = target->next[level];
}
}
if(s->next[level] == target) {
s->next[level] = target->next[level];
}
}
free(target);
}
examples/trees/skiplist/skiplist.c
Here is the header file, Makefile, and test code: skiplist.h, Makefile,
test_skiplist.c.
360
= h(y)] for any fixed keys x =6 y is 1/m, where m is the size of the hash table.
The reason is that the cost of searching for x (with chaining) is linear in the
number of keys already in the table that collide with it. The expected number
of such collisions is the sum of Pr[h(x) = h(y)] over all keys y in the table, or
n/m if we have n keys. So this pairwise collision probability bound is enough to
get the desired n/m behavior out of our table. A family of hash function with
this property is called universal.
How do we get a universal hash family? For strings, we can use a table of random
values, one for each position and possible character in the string. The hash
of a string is then the exclusive or of the random values hashArray[i][s[i]]
corresponding to the actual characters in the string. If our table has size a power
of two, this has the universal property, because if two strings x and y differ in
some position i, then there is only one possible value of hashArray[i][y[i]]
(mod m) that will make the hash functions equal.
Typically to avoid having to build an arbitrarily huge table of random values,
we only has an initial prefix of the string. Here is a hash function based on this
idea, which assumes that the d data structure includes a hashArray field that
contains the random values for this particular hash table:
static unsigned long
hash_function(Dict d, const char *s)
{
unsigned const char *us;
unsigned long h;
int i;
h = 0;
return h;
}
A modified version of the Dict hash table from the chapter on hash tables that
uses this hash function is given here: dict.c, dict.h, test_dict.c, Makefile.
Most of the time, when we’ve talked about the asymptotic performance of data
structures, we have implicitly assumed that the keys we are looking up are of
361
constant size. This means that computing a hash function or comparing two
keys (as in a binary search tree) takes O(1) time. What if this is not the case?
If we consider an m-character string, any reasonable hash function is going to
take O(m) time since it has to look at all of the characters. Similarly, comparing
two m-character strings may also take O(m) time. If we charge for this (as we
should!) then the cost of hash table operations goes from O(1) to O(m) and the
cost of binary search tree operations, even in a balanced tree, goes from O(log n)
to O(m log n). Even sorting becomes more expensive: a sorting algorithm that
does O(n log n) comparisons may now take O(mn log n) time. But maybe we
can exploit the structure of strings to get better performance.
Radix search refers to a variety of data structures that support searching for
strings considered as sequences of digits in some large base (or radix). These
are generally faster than simple binary search trees because they usually only
require examining one byte or less of the target string at each level of the tree,
as compared to every byte in the target in a full string comparison. In many
cases, the best radix search trees are even faster than hash tables, because they
only need to look at a small part of the target string to identify it.
We’ll describe several radix search trees, starting with the simplest and working
up.
4.15.1.1 Tries
A trie is a binary tree (or more generally, a k-ary tree where k is the radix)
where the root represents the empty bit sequence and the two children of a
node representing sequence x represent the extended sequences x0 and x1 (or
generally x0, x1, . . . , x(k − 1)). So a key is not stored at a particular node but
is instead represented bit-by-bit (or digit-by-digit) along some path. Typically
a trie assumes that the set of keys is prefix-free, i.e. that no key is a prefix of
another; in this case there is a one-to-one correspondence between keys and
leaves of the trie. If this is not the case, we can mark internal nodes that
also correspond to the ends of keys, getting a slightly different data structure
known as a digital search tree. For null-terminated strings as in C, the null
terminator ensures that any set of strings is prefix-free.
Given this simple description, a trie storing a single long key would have a very
large number of nodes. A standard optimization is to chop off any path with no
branches in it, so that each leaf corresponds to the shortest unique prefix of a
key. This requires storing the key in the leaf so that we can distinguish different
keys with the same prefix.
The name trie comes from the phrase “information retrieval.” Despite the
etymology, trie is now almost always pronounced like try instead of tree to avoid
362
confusion with other tree data structures.
4.15.1.1.3 Implementation
A typical trie implementation in C might look like this. It uses a GET_BIT macro
similar to the one from the chapter on bit manipulation, except that we reverse
the bits within each byte to get the right sorting order for keys.
typedef struct trie_node *Trie;
363
/* free a trie */
void trie_destroy(Trie);
#include "trie.h"
struct trie_node {
char *key;
struct trie_node *kids[TRIE_BASE];
};
if(trie == 0) {
/* we lost */
return 0;
} else {
/* check that leaf really contains the target */
364
return !strcmp(trie->key, target);
}
}
s2 = malloc(strlen(s) + 1);
assert(s2);
strcpy(s2, s);
return s2;
}
t = malloc(sizeof(*t));
assert(t);
if(key) {
t->key = my_strdup(key);
assert(t->key);
} else {
t->key = 0;
}
return t;
}
365
int bitvalue;
Trie t;
Trie kid;
const char *oldkey;
if(trie == 0) {
return make_trie_node(key);
}
/* else */
/* first we'll search for key */
for(t = trie, bit = 0; !IsLeaf(t); bit++, t = kid) {
kid = t->kids[bitvalue = GET_BIT(key, bit)];
if(kid == 0) {
/* woohoo! easy case */
t->kids[bitvalue] = make_trie_node(key);
return trie;
}
}
/* else */
/* hard case---have to extend the trie */
oldkey = t->key;
#ifdef EXCESSIVE_TIDINESS
t->key = 0; /* not required but makes data structure look tidier */
#endif
/* then split */
t->kids[bitvalue] = make_trie_node(key);
t->kids[!bitvalue] = make_trie_node(oldkey);
return trie;
}
366
/* kill it */
void
trie_destroy(Trie trie)
{
int i;
if(trie) {
for(i = 0; i < TRIE_BASE; i++) {
trie_destroy(trie->kids[i]);
}
if(IsLeaf(trie)) {
free(trie->key);
}
free(trie);
}
}
static void
trie_print_internal(Trie t, int bit)
{
int i;
int kid;
if(t != 0) {
if(IsLeaf(t)) {
for(i = 0; i < bit; i++) putchar(' ');
puts(t->key);
} else {
for(kid = 0; kid < TRIE_BASE; kid++) {
trie_print_internal(t->kids[kid], bit+1);
}
}
}
}
void
trie_print(Trie t)
{
trie_print_internal(t, 0);
}
examples/trees/trie/trie.c
Here is a short test program that demonstrates how to use it:
367
#include <stdio.h>
#include <stdlib.h>
#include "trie.h"
size = 1;
line = malloc(size);
if(line == 0) return 0;
n = 0;
368
int
main(int argc, char **argv)
{
Trie t;
char *line;
t = EMPTY_TRIE;
while((line = getline()) != 0) {
if(!trie_contains(t, line)) {
puts(line);
}
free(line);
}
puts("===");
trie_print(t);
trie_destroy(t);
return 0;
}
examples/trees/trie/test_trie.c
369
typedef struct patricia_node *Patricia;
Now when searching for a key, instead of using the number of nodes visited so
far to figure out which bit to look at, we just read the bit out of the table. This
means in particular that we can skip over any bits that we don’t actually branch
on. We do however have to be more careful to make sure we don’t run off the
end of our target key, since it is possible that when skipping over intermediate
bits we might skip over some that distinguish our target from all keys in the
table, including longer keys. For example, a Patricia tree storing the strings
abc and abd will first test bit position 22, since that’s where abc and abd differ.
This can be trouble if we are looking for x.
Here’s the search code:
int
patricia_contains(Patricia t, const char *key)
{
int key_bits;
370
4.15.1.3 Ternary search trees
Ternary search trees were described by Jon Bentley and Bob Sedgewick in
an article in the April 1988 issue of Dr. Dobb’s Journal, available here.
The basic idea is that each node in the tree stores one character from the key
and three child pointers lt, eq, and gt. If the corresponding character in the
target is equal to the character in the node, we move to the next character in
the target and follow the eq pointer out of the node. If the target is less, follow
the lt pointer but stay at the same character. If the target is greater, follow the
gt pointer and again stay at the same character. When searching for a string,
we walk down the tree until we either reach a node that matches the terminating
NUL (a hit), or follow a null pointer (a miss).
A TST acts a bit like a 256-way trie, except that instead of storing an array
of 256 outgoing pointers, we build something similar to a small binary search
tree for the next character. Note that no explicit balancing is done within these
binary search trees. From a theoretical perspective, the worst case is that we
get a 256-node deep linked-list equivalent at each step, multiplying our search
time by 256 = O(1). In practice, only those characters that actual appear in
some key at this stage will show up, so the O(1) is likely to be a small O(1),
especially if keys are presented in random order.
TSTs are one of the fastest known data structures for implementing dictionaries
using strings as keys, beating both hash tables and tries in most cases. They
can be slower than Patricia trees if the keys have many keys with long matching
prefixes; however, a Patricia-like optimization can be applied to give a com-
pressed ternary search tree that works well even in this case. In practice,
regular TSTs are usually good enough.
Here is a simple implementation of an insert-only TST. The C code includes two
versions of the insert helper routine; the first is the original recursive version
and the second is an iterative version generated by eliminating the tail recursion
from the first.
typedef struct tst_node *TST;
/* free a TST */
void tst_destroy(TST);
371
examples/trees/tst/tst.h
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
#include "tst.h"
struct tst_node {
char key; /* value to split on */
struct tst_node *lt; /* go here if target[index] < value */
struct tst_node *eq; /* go here if target[index] == value */
struct tst_node *gt; /* go here if target[index] > value */
};
while(t) {
if(*key < t->key) {
t = t->lt;
} else if(*key > t->key) {
t = t->gt;
} else if(*key == '\0') {
return 1;
} else {
t = t->eq;
key++;
}
}
return 0;
}
372
}
373
/* add a new key to a TST */
/* and return the new TST */
TST
tst_insert(TST t, const char *key)
{
assert(key);
#ifdef USE_RECURSIVE_INSERT
tst_insert_recursive(&t, key);
#else
tst_insert_iterative(&t, key);
#endif
return t;
}
/* free a TST */
void
tst_destroy(TST t)
{
if(t) {
tst_destroy(t->lt);
tst_destroy(t->eq);
tst_destroy(t->gt);
free(t);
}
}
examples/trees/tst/tst.c
And here is some test code, almost identical to the test code for tries: test_tst.c.
The Dr. Dobb’s article contains additional code for doing deletions and partial
matches, plus some optimizations for inserts.
374
that the algorithm can extract only one bit of information from every call to
compare. Since there are n! possible ways to reorder the input sequence, this
means we need at least log(n!) = O(n log n) calls to compare to finish the sort. If
we are sorting something like strings, this can get particularly expensive, because
calls to strcmp may take time linear in the length of the strings being compared.
In the worst case, sorting n strings of length m each could take O(nm log n)
time.
375
sat
bat
The second pass sorts on the second column, producing no change in the order
(all the characters are the same). The last pass sorts on the first column. This
moves the s after the two bs, but preserves the order of the two words starting
with b. The result is:
bad
bat
sat
There are three downsides to LSB radix sort:
1. All the strings have to be the same length (this is not necessarily a problem
if they are really fixed-width data types like ints).
2. The algorithm used to sort each position must be stable, which may require
more effort than most programmers would like to take.
3. It may be that the late positions in the strings don’t affect the
order, but we have to sort on them anyway. If we are sorting
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa and baaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
we spend a lot of time matching up as against each other.
376
There is a trick we can do analagous to the Dutch flag algorithm where we sort
the array in place. The idea is that we first count the number of elements that
land in each bucket and assign a block of the array for each bucket, keeping
track in each block of an initial prefix of values that belong in the bucket with
the rest not yet processed. We then walk through the buckets swapping out any
elements at the top of the good prefix to the bucket they are supposed to be in.
This procedure puts at least one element in the right bucket for each swap, so
we reorder everything correctly in at most n swaps and O(n) additional work.
To keep track of each bucket, we use two pointers bucket[i] for the first element
of the bucket and top[i] for the first unused element. We could make these be
integer array indices, but this slows the code down by about 10%. This seems to
be a situation where our use of pointers is complicated enough that the compiler
can’t optimize out the array lookups.
#include "radixSort.h"
temp = *a;
*a = *b;
*b = temp;
}
/* this is the internal routine that assumes all strings are equal for the
377
* first k characters */
static void
radixSortInternal(int n, const char **a, int k)
{
int i;
int count[UCHAR_MAX+1]; /* number of strings with given character in position k */
int mode; /* most common position-k character */
const char **bucket[UCHAR_MAX+1]; /* position of character block in output */
const char **top[UCHAR_MAX+1]; /* first unused index in this character block */
if(count[mode] < n) {
378
} else {
/* swap with top of appropriate block */
swapStrings(top[i], top[(unsigned char) top[i][0][k]]++);
}
}
}
} else {
void
radixSort(int n, const char **a)
{
radixSortInternal(n, a, 0);
}
examples/sorting/radixSort/radixSort.c
Some additional files: radixSort.h, test_radixSort.c, Makefile, sortInput.c.
The last is a program that sorts lines on stdin and writes the result to
stdout, similar to the GNU sort utility. When compiled with -O3 and
run on my machine, this runs in about the same time as the standard sort
program when run on a 4.7 million line input file consisting of a random
shuffle of 20 copies of /usr/share/dict/words, provided sort is run with
LANG=C sort < /usr/share/dict/words to keep it from having to deal with
locale-specific collating issues. On other inputs, sort is faster. This is not
bad given how thoroughly sort has been optimized, but is a sign that further
optimization is possible.
379
5 Other topics not covered in detail in 2015
These are mostly leftovers from previous versions of the class where different
topics were emphasized.
5.1.1 Iterators
Suppose we have an abstract data type that represents some sort of container,
such as a list or dictionary. We’d like to be able to do something to every
element of the container; say, count them up. How can we write operations on
the abstract data type to allow this, without exposing the implementation?
To make the problem more concrete, let’s suppose we have an abstract data type
that represents the set of all non-negative numbers less than some fixed bound.
The core of its interface might look like this:
/*
* Abstract data type representing the set of numbers from 0 to
* bound-1 inclusive, where bound is passed in as an argument at creation.
*/
typedef struct nums *Nums;
/* Destructor */
void nums_destroy(Nums);
struct nums {
int bound;
};
380
struct nums *n;
n = malloc(sizeof(*n));
n->bound = bound;
return n;
}
381
nums_contents(Nums n)
{
int *a;
int i;
a = malloc(sizeof(*a) * (n->bound + 1));
for(i = 0; i < n->bound; i++) a[i] = i;
a[n->bound] = -1;
return a;
}
We might use it like this:
sum = 0;
contents = nums_contents(nums);
for(p = contents; *p != -1; p++) {
sum += *p;
}
free(contents);
Despite the naturalness of the approach, returning a sequence in this case leads
to the most code complexity of the options we will examine.
382
create and destroy a separate iterator object that holds the state of the loop.
But for many tasks in C, the first/done/next idiom is a pretty good one.
383
body; just build a struct containing all the variables that it uses, and pass a
pointer to this struct as f_data.
5.1.2 Closures
Sequence
create_sequence(int (*next)(void *data), void *data)
{
Sequence s;
s = malloc(sizeof(*s));
assert(s);
s->next = next;
s->data = data;
return s;
}
int
sequence_next(Sequence s)
{
return s->next(s->data);
}
And here are some examples of sequences:
/* make a constant sequence that always returns x */
static int
constant_sequence_next(void *data)
{
return *((int *) data);
}
384
Sequence
constant_sequence(int x)
{
int *data;
data = malloc(sizeof(*data));
if(data == 0) return 0;
*data = x;
static int
arithmetic_sequence_next(void *data)
{
struct arithmetic_sequence_data *d;
d = data;
d->cur += d->step;
return d->cur;
}
Sequence
arithmetic_sequence(int x, int a)
{
struct arithmetic_sequence_data *d;
d = malloc(sizeof(*d));
if(d == 0) return 0;
385
static int
add_sequences_next(void *data)
{
Sequence *s;
s = data;
return sequence_next(s[0]) + sequence_next(s[1]);
}
Sequence
add_sequences(Sequence s0, Sequence s1)
{
Sequence *s;
s = malloc(2*sizeof(*s));
if(s == 0) return 0;
s[0] = s0;
s[1] = s1;
static int
iterated_function_sequence_next(void *data)
{
struct iterated_function_sequence_data *d;
int retval;
d = data;
retval = d->x;
d->x = d->f(d->x);
return retval;
}
Sequence
iterated_function_sequence(int (*f)(int), int x0)
{
386
struct iterated_function_sequence_data *d;
d = malloc(sizeof(*d));
if(d == 0) return 0;
d->x = x0;
d->f = f;
5.1.3 Objects
Here’s an example of a hierarchy of counter objects. Each counter object has (at
least) three operations: reset, next, and destroy. To call the next operation
on counter c we include c and the first argument, e.g. c->next(c) (one could
write a wrapper to enforce this).
The main trick is that we define a basic counter structure and then extend it
to include additional data, using lots of pointer conversions to make everything
work.
/* use preprocessor to avoid rewriting these */
#define COUNTER_FIELDS \
void (*reset)(struct counter *); \
int (*next)(struct counter *); \
void (*destroy)(struct counter *);
struct counter {
COUNTER_FIELDS
};
387
Counter
make_zero_counter(void)
{
return &Zero_counter;
}
/* new fields */
int init;
int cur;
int (*f)(int); /* update rule */
};
static void
ifs_reset(Counter c)
{
struct ifs_counter *ic;
ic = (struct ifs_counter *) c;
ic->cur = ic->init;
}
static void
ifs_next(Counter c)
{
struct ifs_counter *ic;
int ret;
ic = (struct ifs_counter *) c;
ret = ic->cur;
ic->cur = ic->f(ic->cur);
return ret;
}
Counter
make_ifs_counter(int init, int (*f)(int))
388
{
struct ifs_counter *ic;
ic = malloc(sizeof(*ic));
ic->reset = ifs_reset;
ic->next = ifs_next;
ic->destroy = (void (*)(struct counter *)) free;
ic->init = init;
ic->cur = init;
ic->f = f;
void
print_powers_of_2(void)
{
int i;
Counter c;
c = make_ifs_counter(1, times2);
c->reset(c);
c->destroy(c);
}
389
5.2 Suffix arrays
These are notes on practical implementations of suffix arrays, which are a data
structure for searching quickly for substrings of a given large string.
• Answer from the old days: Fast string searching is the key to dealing with
mountains of information. Why, a modern (c. 1960) electronic computer
can search the equivalent of hundreds of pages of text in just a few hours. . .
• More recent answer:
– We still need to search enormous corpuses of text (see http://www.
google.com).
– Algorithms for finding long repeated substrings or patterns can be
useful for data compression) or detecting plagiarism.
– Finding all occurrence of a particular substring in some huge corpus
is the basis of statistical machine translation.
– We are made out of strings over a particular finite alphabet GATC.
String search is a central tool in computational biology.
Suffix trees and suffix arrays are data structures for representing texts that
allow substring queries like “where does this pattern appear in the text” or “how
many times does this pattern occur in the text” to be answered quickly. Both
work by storing all suffixes of a text, where a suffix is a substring that runs to the
end of the text. Of course, storing actual copies of all suffixes of an n-character
text would take O(n2 ) space, so instead each suffix is represented by a pointer
to its first character.
A suffix array stores all the suffixes sorted in dictionary order. For example,
the suffix array of the string abracadabra is shown below. The actual contents
of the array are the indices in the left-hand column; the right-hand shows the
corresponding suffixes.
390
11 \0
10 a\0
7 abra\0
0 abracadabra\0
3 acadabra\0
5 adabra\0
8 bra\0
1 bracadabra\0
4 cadabra\0
6 dabra\0
9 ra\0
2 racadabra\0
A suffix tree is similar, but instead using an array, we use some sort of tree
data structure to hold the sorted list. A common choice given an alphabet of
some fixed size k is a trie, in which each node at depth d represents a string of
length d, and its up to k children represent all (d + 1)-character extensions of the
string. The advantage of using a suffix trie is that searching for a string of length
m takes O(m) time, since we can just walk down the trie at the rate of one
node per character in m. A further optimization is to replace any long chain of
single-child nodes with a compressed edge labeled with the concatenation all the
characters in the chain. Such compressed suffix tries can not only be searched in
linear time but can also be constructed in linear time with a sufficiently clever
algorithm (we won’t actually do this here). Of course, we could also use a simple
balanced binary tree, which might be preferable if the alphabet is large.
The disadvantage of suffix trees over suffix arrays is that they generally require
more space to store all the internal pointers in the tree. If we are indexing a
huge text (or collection of texts), this extra space may be too expensive.
391
assumption gives an O(n log2 n) running time; this is a factor of log n slower,
but this may be acceptable if programmer time is more important.
The fastest approach is to build a suffix tree in O(n) time and extract the suffix
array by traversing the tree. The only complication is that we need the extra
space to build the tree, although we get it back when we throw the tree away.
392
The idea of the Burrows-Wheeler Transform is to construct an array whose rows
are all cyclic shifts of the input string in dictionary order, and return the last
column of the array. The last column will tend to have long runs of identical
characters, since whenever some substring (like the appears repeatedly in the
input, shifts that put the first character t in the last column will put the rest
of the substring he in the first columns, and the resulting rows will tend to be
sorted together. The relative regularity of the last column means that it will
compress well with even very simple compression algorithms like run-length
encoding.
Below is an example of the Burrows-Wheeler transform in action, with $ marking
end-of-text. The transformed value of abracadabra$ is $drcraaaabba, the last
column of the sorted array; note the long run of a’s (and the shorter run of b’s).
abracadabra$ abracadabra$
bracadabra$a abra$abracad
racadabra$ab acadabra$abr
acadabra$abr adabra$abrac
cadabra$abra a$abracadabr
adabra$abrac bracadabra$a
dabra$abraca --> bra$abracada
abra$abracad cadabra$abra
bra$abracada dabra$abraca
ra$abracadab racadabra$ab
a$abracadabr ra$abracadab
$abracadabra $abracadabra
The most useful property of the Burrows-Wheeler transform is that it can be
inverted; this distinguishes it from other transforms that produce long runs like
simply sorting the characters. We’ll describe two ways to do this; the first is
less efficient, but more easily grasped, and involves rebuilding the array one
column at a time, starting at the left. Observe that the leftmost column is just
all the characters in the string in sorted order; we can recover it by sorting the
rightmost column, which we have to start off with. If we paste the rightmost and
leftmost columns together, we have the list of all 2-character substrings of the
original text; sorting this list gives the first two columns of the array. (Remember
that each copy of the string wraps around from the right to the left.) We can
then paste the rightmost column at the beginning of these two columns, sort
the result, and get the first three columns. Repeating this process eventually
reconstructs the entire array, from which we can read off the original string from
any row. The initial stages of this process for abracadabra$ are shown below:
$ a $a ab $ab abr
d a da ab dab abr
r a ra ac rac aca
c a ca ad cad ada
r a ra a$ ra$ a$a
a b ab br abr bra
393
a -> b ab -> br abr -> bra
a c ac ca aca cad
a d ad da ada dab
b r br ra bra rac
b r br ra bra ra$
a $ a$ $a a$a $ab
Rebuilding the entire array in this fashion takes O(n2 ) time and O(n2 ) space.
In their paper, Burrows and Wheeler showed that one can in fact reconstruct
the original string from just the first and last columns in the array in O(n) time.
Here’s the idea: Suppose that all the characters were distinct. Then after
reconstructing the first column we would know all pairs of adjacent characters.
So we could just start with the last character $ and regenerate the string by
appending at each step the unique successor to the last character so far. If all
characters were distinct, we would never get confused about which character
comes next.
The problem is what to do with pairs with duplicate first characters, like ab
and ac in the example above. We can imagine that each a in the last column is
labeled in some unique way, so that we can talk about the first a or the third a,
but how do we know which a is the one that comes before b or d?
The trick is to look closely at how the original sort works. Look at the rows in
the original transformation. If we look at all rows that start with a, the order
they are sorted in is determined by the suffix after a. These suffixes also appear
as the prefixes of the rows that end with a, since the rows that end with a are
just the rows that start with a rotated one position. It follows that all instances
of the same letter occur in the same order in the first and last columns. So if
we use a stable sort to construct the first column, we will correctly match up
instances of letters.
This method is shown in action below. Each letter is annotated uniquely with
a count of how many identical letters equal or precede it. Sorting recovers the
first column, and combining the last and first columns gives a list of unique
pairs of adjacent annotated characters. Now start with $1 and construct the full
sequence $1 a1 b1 r1 a3 c1 a4 d1 a2 b2 r2 a5 $1. The original string is
obtained by removing the end-of-string markers and annotations: abracadabra.
$1 a1
d1 a2
r1 a3
c1 a4
r2 a5
a1 b1
a2 --> b2
a3 c1
a4 d1
b1 r1
394
b2 r2
a5 $1
Because we are only sorting single characters, we can perform the sort in linear
time using counting sort. Extracting the original string also takes linear time if
implemented reasonably.
struct suffixArray {
size_t n; /* length of string INCLUDING final null */
const char *string; /* original string */
const char **suffix; /* suffix array of length n */
};
/* destructor */
void suffixArrayDestroy(SuffixArray);
395
suffixArraySearch(SuffixArray, const char *substring, size_t *first);
#include "suffixArray.h"
static int
saCompare(const void *s1, const void *s2)
{
return strcmp(*((const char **) s1), *((const char **) s2));
}
SuffixArray
suffixArrayCreate(const char *s)
{
size_t i;
SuffixArray sa;
sa = malloc(sizeof(*sa));
assert(sa);
sa->n = strlen(s) + 1;
sa->string = s;
396
return sa;
}
void
suffixArrayDestroy(SuffixArray sa)
{
free(sa->suffix);
free(sa);
}
size_t
suffixArraySearch(SuffixArray sa, const char *substring, size_t *first)
{
size_t lo;
size_t hi;
size_t mid;
size_t len;
int cmp;
len = strlen(substring);
if(cmp == 0) {
/* we have a winner */
/* search backwards and forwards for first and last */
for(lo = mid; lo > 0 && strncmp(sa->suffix[lo-1], substring, len) == 0; lo--);
for(hi = mid; hi < sa->n && strncmp(sa->suffix[hi+1], substring, len) == 0; hi++
if(first) {
*first = lo;
}
return hi - lo + 1;
} else if(cmp < 0) {
lo = mid;
} else {
hi = mid;
}
397
}
return 0;
}
char *
suffixArrayBWT(SuffixArray sa)
{
char *bwt;
size_t i;
bwt = malloc(sa->n);
assert(bwt);
return bwt;
}
char *
inverseBWT(size_t len, const char *s)
{
/* basic trick: stable sort of s gives successor indices */
/* then we just thread through starting from the nul */
size_t *successor;
int c;
size_t count[UCHAR_MAX+1];
size_t offset[UCHAR_MAX+1];
size_t i;
char *ret;
size_t thread;
/* counting sort */
for(c = 0; c <= UCHAR_MAX; c++) {
count[c] = 0;
398
}
offset[0] = 0;
return ret;
}
examples/suffixArray/suffixArray.c
Here is a Makefile and test code: Makefile, testSuffixArray.c.
The output of make test shows all occurrences of a target string, the Burrows-
Wheeler transform of the source string (second-to-last line), and its inversion
(last line, which is just the original string):
$ make test
/bin/echo -n abracadabra-abracadabra-shmabracadabra | ./testSuffixArray abra
Count: 6
abra
abra-abr
abra-shm
abracada
abracada
abracada
aaarrrdddm\x00-rrrcccaaaaaaaaaaaashbbbbbb-
399
abracadabra-abracadabra-shmabracadabra
5.4 C++
Here we will describe some basic features of C++ that are useful for implementing
abstract data types. Like all programming languages, C++ comes with an
ideology, which in this case emphasizes object-oriented features like inheritance.
We will be ignoring this ideology and treating C++ as an improved version of C.
The goal here is not to teach you all of C++, which would take a while, but
instead to give you some hints for why you might want to learn C++ on your own.
If you decide to learn C++ for real, Bjarne Stroustrup’s The C++ Programming
Language is the definitive source. A classic tutorial here aimed at C programmers
introduces C++ features one at a time (some of these features have since migrated
into C). The web site http://www.cplusplus.com has extensive tutorials and
documentation.
int
main(int argc, const char **argv)
{
std::cout << "hi\n";
return 0;
}
examples/c++/helloworld.cpp
Compile this using g++ instead of gcc. Make shows how it is done:
$ make helloworld
g++ helloworld.cpp -o helloworld
Or we could use an explicit Makefile:
CPP=g++
CPPFLAGS=-g3 -Wall
helloworld: helloworld.o
$(CPP) $(CPPFLAGS) -o $@ $^
Now the compilation looks like this:
400
$ make helloworld
g++ -g3 -Wall -c -o helloworld.o helloworld.cpp
g++ -g3 -Wall -o helloworld helloworld.o
The main difference from the C version:
1. #include <stdio.h> is replaced by #include <iostream>, which gets
the C++ version of the stdio library.
2. printf("hi\n") is replaced by std::cout << "hi\n". The stream
std::cout is the C++ wrapper for stdout; you should read this variable
name as cout in the std namespace. The << operator is overloaded for
streams so that it sends its right argument out on its left argument (see
the discussion of operator overloading below). You can also do things like
std::cout << 37, std::cout << 'q', std::cout << 4.7, etc. These
all do pretty much what you expect.
If you don’t like typing std:: before all the built-in functions and variables, you
can put using namespace std somewhere early in your program, like this:
#include <iostream>
int
main(int argc, const char **argv)
{
cout << "hi\n";
return 0;
}
examples/c++/helloworld_using.cpp
5.4.2 References
401
void increment(int &x)
{
x++;
}
The int &x declaration says that x is a reference to whatever variable is passed
as the argument to increment. A reference acts exactly like a pointer that has
already had * applied to it. You can even write &x to get a pointer to the original
variable if you want to for some reason.
As with pointers, it’s polite to mark a reference with const if you don’t intend
to modify the original object:
void reportWeight(const SumoWrestler &huge)
{
cout << huge.getWeight();
}
References are also used as a return type to chain operators together; in the
expression
cout << "hi" << '\n';
the return type of the first << operator is an ostream & reference (as is cout);
this means that the '\n' gets sent to the same object. We could make the
return value be just an ostream, but then cout would be copied, which could
be expensive and would mean that the copy was no longer working on the same
internal state as the original. This same trick is used when overloading the
assignment operator.
C++ lets you define multiple functions with the same name, where the choice of
which function to call depends on the type of its arguments. Here is a program
that demonstrates this feature:
#include <iostream>
const char *
typeName(int x)
{
return "int";
}
const char *
typeName(double x)
402
{
return "double";
}
const char *
typeName(char x)
{
return "char";
}
int
main(int argc, const char **argv)
{
cout << "The type of " << 3 << " is " << typeName(3) << ".\n";
cout << "The type of " << 3.1 << " is " << typeName(3.1) << ".\n";
cout << "The type of " << 'c' << " is " << typeName('c') << ".\n";
return 0;
}
examples/c++/functionOverloading.cpp
And here is what it looks like when we compile and run it:
$ make functionOverloading
g++ functionOverloading.cpp -o functionOverloading
$ ./functionOverloading
The type of 3 is int.
The type of 3.1 is double.
The type of c is char.
Internally, g++ compiles three separate functions with different (and ugly) names,
and when you use typeName on an object of a particular type, g++ picks the one
whose type matches. This is similar to what happens with built-in operators in
straight C, where + means different things depending on whether you apply it
to a pair of ints, a pair of doubles, or a pointer and an int, but C++ lets you
do it with your own functions.
5.4.4 Classes
C++ allows you to declare classes that look suspiciously like structs. The main
differences between a class and a C-style struct are that (a) classes provide
member functions or methods that operate on instances of the class and
that are called using a struct-like syntax; and (b) classes can distinguish between
private members (only accessible to methods of the class) and public members
(accessible to everybody).
403
In C, we organize abstract data types by putting the representation in a struct
and putting the operations on the data type in functions that work on this struct,
often giving the functions a prefix that hints at the type of its target (mostly to
avoid namespace collisions). Classes in C++ make this connection between a
data structure and the operations on it much more explicit.
Here is a simple example of a C++ class in action:
#include <iostream>
Counter::Counter() { value = 0; }
Counter::Counter(int initialValue) { value = initialValue; }
Counter::~Counter() { cerr << "counter de-allocated with value " << value << '\n'; }
int Counter::read() { return value; }
void Counter::increment() { value++; }
int
main(int argc, const char **argv)
{
Counter c;
Counter c10(10);
return 0;
}
404
examples/c++/counter.cpp
Things to notice:
1. In the class Counter declaration, the public: label introduces the public
members of the class. The member value is only accessible to member
functions of Counter. This enforces much stronger information hiding
than the default in C, although one can still use void * trickery to hunt
down and extract supposedly private data in C++ objects.
2. In addition to the member function declarations in the class declara-
tion, we also need to provide definitions. These look like ordinary func-
tion definitions, except that the class name is prepended using :: as in
Counter::read.
3. Member functions are called using struct access syntax, as in c.read().
Conceptually, each instance of a class has its own member functions, so
that c.read is the function for reading c while c10.read is the function
for reading c10. Inside a member function, names of class members refer to
members of the current instance; value inside c.read is c.value (which
otherwise is not accessible, since c.value is not public).
4. Two special member functions are Counter::Counter() and Counter::Counter(int).
These are constructors, and are identifiable as such because they are
named after the class. A constructor is called whenever a new instance
of the class is created. If you create an instance with no arguments
(as in the declaration Counter c;), you get the constructor with no
arguments. If you create an instance with arguments (as in the declaration
Counter c10(10);), you get the version with the appropriate arguments.
This is just another example of function overloading. If you don’t define
any constructors, C++ supplies a default constructor that takes no
arguments and does nothing. Note that constructors don’t have a return
type (you don’t need to preface them with void).
5. The special member function Counter::~Counter() is a destructor; it is
called when an object of type Counter is de-allocated (say, when returning
from a function with a local variable of this type). This particular destructor
is not very useful. Destructors are mostly important for objects that allocate
their own storage that needs to be de-allocated when the object is; see the
section on storage allocation below.
Compiling and running this program gives the following output. Note that the
last two lines are produced by the destructor.
c starts at 0
c after one increment is 1
c10 starts at 10
c10 after two increments is 10
counter de-allocated with value 10
counter de-allocated with value 3
One subtle difference between C and C++ is that C++ uses empty parentheses
405
() for functions with no arguments, where C would use (void). This is a bit
of a historical artifact, having to do with C allowing () for functions whose
arguments are not specified in the declaration (which was standard practice
before ANSI C).
Curiously, C++ also allows you to declare structs, with the interpretation that
a struct is exactly like a class except that all members are public by default.
So if you change class to struct in the program above, it will do exactly the
same thing. In practice, nobody who codes in C++ does this; the feature is
mostly useful to allow C code with structs to mix with C++ code.
Sometimes when you define a new class, you also want to define new interpre-
tations of operators on that class. Here is an example of a class that defines
elements of the max-plus algebra over ints. This gives us objects that act
like ints, except that the + operator now returns the larger of its arguments and
the * operator now returns the sum.25
The mechanism in C++ for doing this is to define member functions with names
operatorsomething where something is the name of the operator we want to
define. These member functions take one less argument that the operator they
define; in effect, x + y becomes syntactic sugar for x.operator+(y) (which,
amazingly, is actually legal C++). Because these are member functions, they
are allowed to access members of other instances of the same class that would
normally be hidden.
This same mechanism is also used to define automatic type conversions out
of a type: the MaxPlus::operator int() function allows C++ to convert a
MaxPlus object to an int whenever it needs to (for example, to feed it to cout).
(Automatic type conversions into a type happen if you provide an appropriate
constructor.)
#include <iostream>
#include <algorithm> // for max
where a+b is the time to do a and b in parallel, and a*b is the time to do a and b sequentially.
The reason for making the first case + and the second case * is because this makes the
distributive law a*(b+c) = (a*b)+(a*c) work. It also allows tricks like matrix multiplication
using the standard definition. See http://maxplus.org for more than you probably want to
know about this.
406
public:
MaxPlus(int);
MaxPlus operator+(const MaxPlus &);
MaxPlus operator*(const MaxPlus &);
operator int();
};
MaxPlus::MaxPlus(int x) { value = x; }
MaxPlus
MaxPlus::operator*(const MaxPlus &other)
{
return MaxPlus(value + other.value);
}
MaxPlus
MaxPlus::operator+(const MaxPlus &other)
{
/* std::max does what you expect */
return MaxPlus(max(value, other.value));
}
int
main(int argc, const char **argv)
{
cout << "2+3 == " << (MaxPlus(2) + MaxPlus(3)) << '\n';
cout << "2*3 == " << (MaxPlus(2) * MaxPlus(3)) << '\n';
return 0;
}
examples/c++/maxPlus.cpp
Avoid the temptation to overuse operator overloading, as it can be dangerous if
used to obfuscate what an operator normally does:
MaxPlus::operator--() { godzilla.eat(tokyo); }
The general rule of thumb is that you should probably only do operator overload-
ing if you really are making things that act like numbers (yes, cout << violates
this).
Automatic type conversions can be particularly dangerous. The line
cout << (MaxPlus(2) + 3) << '\n';
is ambiguous: should the compiler convert MaxPlus(2) to an int using the
407
MaxPlus(int) constructor and use ordinary integer addition or convert 3 to
a MaxPlus using MaxPlus::operator int() and use funky MaxPlus addition?
Fortunately most C++ compilers will complain about the ambiguity and fail
rather than guessing wrong.
5.4.6 Templates
One of the things we kept running into in this class was that if we defined a
container type like a hash table, binary search tree, or priority queue, we had
to either bake in the type of the data it held or do horrible tricks with void *
pointers to work around the C type system. C++ includes a semi-principled
work-around for this problem known as templates. These are essentially macros
that take a type name as an argument, that are expanded as needed to produce
functions or classes with specific types (see Macros for an example of how to do
this if you only have C).
Typical use is to prefix a definition with template <class T> and then use T
as a type name throughout:
template <class T>
T add1(T x)
{
return x + ((T) 1);
}
Note the explicit cast to T of 1; this avoids ambiguities that might arise with
automatic type conversions.
If you put this definition in a program, you can then apply add1 to any type
that has a + operator and that you can convert 1 to. For example, the output of
this code fragment:
cout << "add1(3) == " << add1(3) << '\n';
cout << "add1(3.1) == " << add1(3.1) << '\n';
cout << "add1('c') == " << add1('c') << '\n';
cout << "add1(MaxPlus(0)) == " << add1(MaxPlus(0)) << '\n';
cout << "add1(MaxPlus(2)) == " << add1(MaxPlus(2)) << '\n';
is
add1(3) == 4
add1(3.1) == 4.1
add1('c') == d
add1(MaxPlus(0)) == 1
add1(MaxPlus(2)) == 2
By default, C++ will instantiate a template to whatever type fits in its argument.
If you want to force a particular version, you can put the type in angle brackets
after the name of whatever you defined. For example,
408
cout << "add1<int>(3.1) == " << add1<int>(3.1) << '\n';
produces
add1<int>(3.1) == 4
because add1<int> forces its argument to be converted to an int (truncating
to 3) before adding one to it.
Because templates are really macros that get expanded as needed, it is common
to put templates in header (.h) files rather than in .cpp files. See the stack
implementation below for an example of this.
5.4.7 Exceptions
int fail()
{
throw "you lose";
return 5;
}
int
main(int argc, const char **argv)
{
try {
cout << fail() << '\n';
}
409
catch(const char *s) {
cerr << "Caught error: " << s << '\n';
}
return 0;
}
examples/c++/exception.cpp
In action:
$ make exception
g++ -g3 -Wall exception.cpp -o exception
$ ./exception
Caught error: you lose
Note the use of cerr instead of cout. This sends the error message to stderr.
A try..catch statement will catch an exception only if the type matches the
type of the argument to the catch part of the statement. This can be used to
pick and choose which exceptions you want to catch. See http://www.cplusplus.
com/doc/tutorial/exceptions/ for some examples and descriptions of some C++
standard library exceptions.
C++ programs generally don’t use malloc and free, but instead use the built-in
C++ operators new and delete. The advantage of new and delete is that they
know about types: not only does this mean that you don’t have to play games
with sizeof to figure out how much space to allocate, but if you allocate a new
object from a class with a constructor, the constructor gets called to initialize
the object, and if you delete an object, its destructor (if it has one) is called.
There are two versions of new and delete, depending on whether you want
to allocate just one object or an array of objects, plus some special syntax for
passing constructor arguments:
• To allocate a single object, use new type.
• To allocate an array of objects, use new type[size]. As with malloc, both
operations return a pointer to type.
• If you want to pass arguments to a constructor for type, use new
type(args). This only works with the single-object version, so you can’t
do new SomeClass[12] unless SomeClass has a constructor that takes no
arguments.
• To de-allocate a single object, use delete pointer-to-object.
• To de-allocate an array, use delete [] pointer-to-base-of-array. Mixing
new with delete [] or vice versa is an error that may or may not be
410
detected by the compiler. Mixing either with malloc or free is a very bad
idea.
The program below gives examples of new and delete in action:
#include <iostream>
#include <cassert>
class Noisy {
int id;
public:
Noisy(int); // create a noisy object with this id
~Noisy();
};
Noisy::Noisy(int initId) {
id = initId;
cout << "Noisy object created with id " << id << '\n';
}
Noisy::~Noisy() {
cout << "Noisy object destroyed with id " << id << '\n';
}
int
main(int argc, const char **argv)
{
int *p;
int *a;
const int n = 100;
Noisy n1(1);
Noisy *n2;
p = new int;
a = new int[n];
n2 = new Noisy(2);
*p = 5;
assert(*p == 5);
411
assert(a[i] == i);
}
delete [] a;
delete p;
delete n2;
return 0;
}
examples/c++/allocation.cpp
412
Stack(); /* create a new empty stack */
delete [] contents;
413
size = other.size;
top = other.top;
contents = new T[size];
return *this;
}
delete [] contents;
contents = newContents;
size = newSize;
}
contents[top++] = elt;
}
414
Here is some code demonstrating use of the stack:
#include <iostream>
#include "stack.h"
int
main(int argc, const char **argv)
{
Stack<int> s;
Stack<int> s2;
try {
s.push(1);
s.push(2);
s.push(3);
s2 = s;
try {
s2.pop();
} catch(const char *err) {
cout << "Caught expected exception " << err << '\n';
}
return 0;
}
415
examples/c++/stack/testStack.cpp
int
main(int argc, const char **argv)
{
stack<int> s;
stack<int> s2;
s.push(1);
s.push(2);
s.push(3);
s2 = s;
return 0;
}
examples/c++/stack/stdStack.cpp
416
One difference between the standard stack and our stack is that std::stack’s
pop member function doesn’t return anything. So we have to use top to get the
top element before popping it.
There is a chart of all the standard library data structures at http://www.
cplusplus.com/reference/stl/.
The main thing we’ve omitted here is any discussion of object-oriented features
of C++, particularly inheritance. These are not immediately useful for the
abstract-data-type style of programming we’ve used in CS223, but can be helpful
for building more complicated systems, where we might want to have various
specialized classes of objects that can all be approached using a common interface
represented by a class that they inherit from. If you are interested in exploring
these tools further, the CS department occasionally offers a class on object-
oriented programming; Mike Fischer’s lecture notes from the last time this
course was offered can be found at http://zoo.cs.yale.edu/classes/cs427/2011a/
lectures.html.
417
by itself. Typically, this will be a single function or a group of functions that
together implement some data structure.
In C, these will often make up the contents of a single source file. Though this is
probably not the best approach if you are building a production-quality testing
framework, a simple way to include unit tests in a program is to append to each
source file a test main function that can be enabled by defining a macro (I like
TEST_MAIN). You can then build this file by itself with the macro defined to get
a stand-alone test program for just this code.
5.5.1.2 Example
Here is an example of a simple data structure with some built-in test code
conditionally compiled by defining TEST_MAIN. The data structure implements a
counter with built-in overflow protection. The counter interface does not provide
the ability to read the counter value; instead, the user can only tell if it is zero
or not.
Because the counter is implemented internally as a uint64_t, black-box testing
of what happens with too many increments would take centuries. So we include
some white-box tests that directly access the counter value to set up this (arguably
unnecessary) test case.
The code is given below. We include both the interface file and the implemen-
tation, as well as a Makefile showing how to build and run the test program.
The Makefile includes some extra arguments to gcc to turn on the TEST_MAIN
macro and supply the extra information needed to run gcov. If you type make
test, it will make and run testCounter, and then run gcov to verify that we
did in fact hit all lines of code in the program.
418
/*
* Abstract counter type.
*
* You can increment it, decrement it, and test for zero.
*
* Increment and decrement operations return 1 if successful,
* 0 if the operation would cause underflow or overflow.
*/
/* destroy a counter */
void counterDestroy(Counter *);
#include <stdint.h>
struct counter {
uint64_t value;
};
419
c = malloc(sizeof(Counter));
assert(c);
c->value = 0;
return c;
}
/* destroy a counter */
void
counterDestroy(Counter *c)
{
free(c);
}
420
#ifdef TEST_MAIN
int
main(int argc, char **argv)
{
Counter *c;
assert(counterIsZero(c));
assert(counterIncrement(c) == 1); /* 1 */
assert(!counterIsZero(c));
assert(counterIncrement(c) == 1); /* 2 */
assert(!counterIsZero(c));
assert(counterDecrement(c) == 1); /* 1 */
assert(!counterIsZero(c));
assert(counterDecrement(c) == 1); /* 0 */
assert(counterIsZero(c));
assert(counterDecrement(c) == 0); /* 0 */
assert(counterIsZero(c));
assert(counterIncrement(c) == 1); /* 1 */
assert(!counterIsZero(c));
counterDestroy(c);
assert(c->value == 0);
assert(counterIncrement(c) == 1); /* 1 */
assert(c->value == 1);
assert(counterIncrement(c) == 1); /* 2 */
assert(c->value == 2);
assert(counterDecrement(c) == 1); /* 1 */
assert(c->value == 1);
assert(counterDecrement(c) == 1); /* 0 */
assert(c->value == 0);
assert(counterDecrement(c) == 0); /* 0 */
assert(c->value == 0);
assert(counterIncrement(c) == 1); /* 1 */
assert(c->value == 1);
421
assert(counterDecrement(c) == 1); /* COUNTER_MAX-1 */
assert(c->value == COUNTER_MAX-1);
assert(counterIncrement(c) == 1); /* COUNTER_MAX */
assert(c->value == COUNTER_MAX);
counterDestroy(c);
return 0;
}
#endif
examples/unitTest/counter.c
CC=c99
CFLAGS=-g3 -pedantic -Wall
all: seqprinter
test: seqprinter
./seqprinter
clean:
$(RM) -f seqprinter *.o
examples/ADT/sequence/Makefile
Here are some older notes on testing using a test harness that does some basic
tricks like catching segmentation faults so that a program can keep going even if
one test fails.
5.5.2.1.1 stack.h
422
/*
* This is an "opaque struct"; it discourages people from looking at
* the inside of our structure. The actual definiton of struct stack
* is contained in stack.c.
*/
typedef struct stack *Stack;
5.5.2.2.1 test-stack.c
#include <stdio.h>
#include <setjmp.h>
#include <signal.h>
#include <unistd.h>
#include <stdlib.h>
423
#include "stack.h"
#include "tester.h"
int
main(int argc, char **argv)
{
Stack s;
int i;
tester_init();
/* 25 */ TEST_ASSERT(s != 0);
/* 32 */ TEST(stack_isempty(s), 0);
/* 33 */ TEST(stack_pop(s), 3);
/* 34 */ TEST(stack_isempty(s), 0);
/* 35 */ TEST(stack_pop(s), 2);
/* 36 */ TEST(stack_isempty(s), 0);
/* 37 */ TEST(stack_pop(s), 1);
/* 38 */ TEST(stack_isempty(s), 1);
/* 39 */ TEST(stack_pop(s), STACK_EMPTY);
/* 40 */ TEST(stack_isempty(s), 1);
/* 41 */ TEST(stack_pop(s), STACK_EMPTY);
424
stack_push(s, i);
}
for(i = 0; i < STRESS_TEST_ITERATIONS; i++) {
stack_push(s, 957);
if(stack_pop(s) != 957) {
/* 60 */ FAIL("wanted 957 but didn't get it");
abort();
}
}
for(i = STRESS_TEST_ITERATIONS - 1; i >= 0; i--) {
if(stack_isempty(s)) {
/* 66 */ FAIL("stack empty too early");
abort();
}
if(stack_pop(s) != i) {
/* 70 */ FAIL("got wrong value!");
abort();
}
}
} ENDTRY; /* 74 */
/* 76 */ TEST(stack_isempty(s), 1);
tester_report(stdout, argv[0]);
return tester_result();
}
There is a lot of test code here. In practice, we might write just a few tests to
start off with, and, to be honest, I didn’t write all of this at once. But you can
never have too many tests— if nothing else, they give an immediate sense of
gratification as the number of failed tests drops.
5.5.2.3 Makefile
• Finally, we’ll write a Makefile:
5.5.2.3.1 Makefile
CC=gcc
CFLAGS=-g3 -Wall -ansi -pedantic
all:
test: test-stack
425
./test-stack
@echo OK!
Of course, we still can’t compile anything, because we don’t have any implemen-
tation. Let’s fix that. To make it easy to write, we will try to add as little as
possible to what we already have in stack.h:
5.5.3.1 stack.c
#include <stdlib.h>
#include "stack.h"
426
test-stack.c:45: TEST FAILED: stack_isempty(s) -> 1 but expected 0
test-stack.c:46: TEST FAILED: stack_pop(s) -> -1 but expected 4
test-stack.c:60: wanted 957 but didn't get it
test-stack.c:74: Aborted (signal 6)
./test-stack: errors 8/17, signals 1, FAILs 1
make[1]: *** [test] Error 8
Hooray! It compiles on the first try! (Well, not really, but let’s pretend it did.)
Unfortunately, it only passes any tests at all by pure dumb luck. But now we
just need to get the code to pass a few more tests.
Here’s a first attempt at a stack that suffers from some artificial limits. We
retain the structure of the original broken implementation, we just put a few
more lines of code in and format it more expansively.
5.5.4.1 stack.c
#include <stdlib.h>
#include "stack.h"
struct stack {
int top;
int data[MAX_STACK_SIZE];
};
Stack
stack_create(void)
{
struct stack *s;
s = malloc(sizeof(*s));
s->top = 0;
return s;
}
void
stack_destroy(Stack s)
{
free(s);
}
427
void
stack_push(Stack s, int elem)
{
s->data[(s->top)++] = elem;
}
int
stack_pop(Stack s)
{
return s->data[--(s->top)];
}
int
stack_isempty(Stack s)
{
return s->top == 0;
}
Let’s see what happens now:
$ make test
gcc -g3 -Wall -ansi -pedantic -c -o test-stack.o test-stack.c
gcc -g3 -Wall -ansi -pedantic -c -o tester.o tester.c
gcc -g3 -Wall -ansi -pedantic -c -o stack.o stack.c
gcc -g3 -Wall -ansi -pedantic -o test-stack test-stack.o tester.o stack.o
./test-stack
test-stack.c:40: TEST FAILED: stack_isempty(s) -> 0 but expected 1
test-stack.c:41: TEST FAILED: stack_pop(s) -> 409 but expected -1
test-stack.c:47: TEST FAILED: stack_isempty(s) -> 0 but expected 1
test-stack.c:48: TEST FAILED: stack_pop(s) -> 0 but expected -1
test-stack.c:49: TEST FAILED: stack_isempty(s) -> 0 but expected 1
test-stack.c:74: Segmentation fault (signal 11)
test-stack.c:76: TEST FAILED: stack_isempty(s) -> 0 but expected 1
free(): invalid pointer 0x804b830!
./test-stack: errors 6/17, signals 1, FAILs 0
make[1]: *** [test] Error 6
There are still errors, but we get past several initial tests before things blow up.
Looking back at the line numbers in test-stack.c, we see that the first failed
test is the one that checks if the stack is empty after we pop from an empty stack.
The code for stack_isempty looks pretty clean, so what happened? Somewhere
s->top got set to a nonzero value, and the only place this can happen is inside
stack_pop. Aha! There’s no check in stack_pop for an empty stack, so it’s
decrementing s->top past 0. (Exercise: why didn’t the test of stack_pop fail?)
428
5.5.5 First fix
If we’re lucky, fixing this problem will make the later tests happier. Let’s try a
new version of stack_pop. We’ll leave everything else the same.
int
stack_pop(Stack s)
{
if(stack_isempty(s)) {
return STACK_EMPTY;
} else {
return s->data[--(s->top)];
}
}
And now we get:
$ make test
gcc -g3 -Wall -ansi -pedantic -c -o test-stack.o test-stack.c
gcc -g3 -Wall -ansi -pedantic -c -o tester.o tester.c
gcc -g3 -Wall -ansi -pedantic -c -o stack.o stack.c
gcc -g3 -Wall -ansi -pedantic -o test-stack test-stack.o tester.o stack.o
./test-stack
test-stack.c:74: Segmentation fault (signal 11)
test-stack.c:76: TEST FAILED: stack_isempty(s) -> 0 but expected 1
./test-stack: errors 1/17, signals 1, FAILs 0
make[1]: *** [test] Error 1
Which is much nicer. We are still failing the stress test, but that’s not terribly
surprising.
After some more tinkering, this is what I ended up with. This version uses a
malloc’d data field, and realloc’s it when the stack gets too big.
5.5.6.1 stack.c
#include <stdlib.h>
#include "stack.h"
struct stack {
int top; /* first unused slot in data */
int size; /* number of slots in data */
int *data; /* stack contents */
};
429
#define INITIAL_STACK_SIZE (1)
#define STACK_SIZE_MULTIPLIER (2)
Stack
stack_create(void)
{
struct stack *s;
s = malloc(sizeof(*s));
if(s == 0) return 0;
s->top = 0;
s->size = INITIAL_STACK_SIZE;
s->data = malloc(s->size * sizeof(*(s->data)));
if(s->data == 0) return 0;
/* else everything is ok */
return s;
}
void
stack_destroy(Stack s)
{
free(s->data);
free(s);
}
void
stack_push(Stack s, int elem)
{
if(s->top == s->size) {
/* need more space */
s->size *= STACK_SIZE_MULTIPLIER;
s->data = realloc(s->data, s->size * sizeof(*(s->data)));
if(s->data == 0) {
abort(); /* we have no other way to signal failure :-( */
}
}
/* now there is enough room */
s->data[s->top++] = elem;
}
int
stack_pop(Stack s)
{
430
if(stack_isempty(s)) {
return STACK_EMPTY;
} else {
return s->data[--(s->top)];
}
}
int
stack_isempty(Stack s)
{
return s->top == 0;
}
At last we have a version that passes all tests:
$ make test
gcc -g3 -Wall -ansi -pedantic -c -o test-stack.o test-stack.c
gcc -g3 -Wall -ansi -pedantic -c -o tester.o tester.c
gcc -g3 -Wall -ansi -pedantic -c -o stack.o stack.c
gcc -g3 -Wall -ansi -pedantic -o test-stack test-stack.o tester.o stack.o
./test-stack
OK!
5.5.7 Moral
Writing a big program all at once is hard. If you can break the problem down
into little problems, it becomes easier. “Test first” is a strategy not just for
getting a well-tested program, but for giving you something easy to do at each
step— it’s usually not too hard to write one more test, and it’s usually not too
hard to get just one test working. If you can keep taking those small, easy steps,
eventually you will run out of failed tests and have a working program.
/*
* Test macros.
*
* Usage:
*
* #include <setjmp.h>
* #include <stdio.h>
* #include <signal.h>
* #include <unistd.h>
*
* testerInit(); -- Initialize internal data structures.
431
* testerReport(FILE *, "name"); -- Print report.
* testerResult(); -- Returns # of failed tests.
*
* TRY { code } ENDTRY;
*
* Wraps code to catch seg faults, illegal instructions, etc. May not be
* nested.
* Prints a warning if a signal is caught.
* To enforce a maximum time, set alarm before entering.
*
* TEST(expr, expected_value);
*
* Evaluates expr (which should yield an integer value) inside a TRY.
* Prints a warning if evaluating expr causes a fault or returns a value
* not equal to expected_value.
*
* TEST_ASSERT(expr)
*
* Equivalent to TEST(!(expr), 0)
*
* You can also cause your own failures with FAIL:
*
* TRY {
* x = 1;
* if(x == 2) FAIL("why is x 2?");
* } ENDTRY;
*
* To limit the time taken by a test, call tester_set_time_limit with
* a new limit in seconds, e.g.
*
* tester_set_time_limit(1);
* TRY { while(1); } ENDTRY;
*
* There is an initial default limit of 10 seconds.
* If you don't want any limit, set the limit to 0.
*
*/
432
int expr_value; /* expression value */
int setjmp_return; /* return value from setjmp */
int try_failed; /* true if last try failed */
int user_fails; /* number of calls to FAIL */
int time_limit; /* time limit for TRY */
} TesterData;
/* another atrocity */
#define TEST(expr, expected_value) \
TesterData.tests++; \
TesterData.errors++; /* guilty until proven innocent */ \
433
TRY { TesterData.expr_value = (expr); \
if(TesterData.expr_value != expected_value) { \
fprintf(stderr, "%s:%d: TEST FAILED: %s -> %d but expected %d\n", \
__FILE__, __LINE__, __STRING(expr), \
TesterData.expr_value, expected_value); \
} else { \
TesterData.errors--; \
} \
} \
ENDTRY; \
if(TesterData.try_failed) \
fprintf(stderr, "%s:%d: TEST FAILED: %s caught signal\n", \
__FILE__, __LINE__, __STRING(expr))
#include <stdio.h>
#include <signal.h>
#include <string.h>
#include <setjmp.h>
#include "tester.h"
const char *
testerStrsignal(int sig)
{
return strsignal(sig);
}
static void
tester_sighandler(int signal)
{
if(TesterData.escape_hatch_active) {
TesterData.escape_hatch_active = 0;
longjmp(TesterData.escape_hatch, signal);
}
}
434
void
testerInit(void)
{
TesterData.escape_hatch_active = 0;
TesterData.tests = 0;
TesterData.errors = 0;
TesterData.signals = 0;
TesterData.user_fails = 0;
signal(SIGSEGV, tester_sighandler);
signal(SIGILL, tester_sighandler);
signal(SIGFPE, tester_sighandler);
signal(SIGALRM, tester_sighandler);
signal(SIGBUS, tester_sighandler);
signal(SIGABRT, tester_sighandler);
}
void
testerReport(FILE *f, const char *preamble)
{
if(TesterData.errors != 0 || TesterData.signals != 0) {
fprintf(f, "%s: errors %d/%d, signals %d, FAILs %d\n",
preamble,
TesterData.errors,
TesterData.tests,
TesterData.signals,
TesterData.user_fails);
}
}
int
testerResult(void)
{
return TesterData.errors;
}
void
tester_set_time_limit(int t)
{
TesterData.time_limit = t;
}
examples/testHarness/tester.c
435
5.6 Algorithm design techniques
The fundamental principle of algorithm design was best expressed by the math-
ematician George Polya: “If there is a problem you can’t solve, then there is
an easier problem you can solve: find it.” For computers, the situation is even
better: if there is any technique to make a problem easier even by a tiny bit, then
you can repeat the technique—possibly millions or even billions of times—until
the problem becomes trivial.
For example, suppose we want to find the maximum element of an array of n
ints, but we are as dumb as bricks, so it doesn’t occur to us to iterate through
the array keeping track of the largest value seen so far. We might instead be
able to solve the problem by observing that the maximum element is either (a)
the last element, or (b) the maximum of the first n − 1 elements, depending on
which is bigger. Figuring out (b) is an easier version of the original problem, so
we are pretty much done once we’ve realized we can split the problem in this
way. Here’s the code:
/* returns maximum of the n elements in a */
int
max_element(int a[], int n)
{
int prefix_max;
if(n == 1) {
return a[0];
} else {
prefix_max = max_element(a, n-1);
if(prefix_max < a[n-1]) {
return a[n-1];
} else {
return prefix_max;
}
}
}
Note that we need a special case for a 1-element array, because the empty prefix
of such an array has no maximum element. We also assert that the array
contains at least one element, just to avoid mischief.
One problem with this algorithm (at least when coding in C) is that the recursion
may get very deep. Fortunately, there is a straightforward way to convert the
recursion to a loop. The idea is that instead of returning a value from the
436
recursive call, we put it in a variable that gets used in the next pass through the
loop. The result is
/* returns maximum of the n elements in a */
int
max_element(int a[], int n)
{
int i; /* this replaces n-1 from the recursive version */
int prefix_max;
437
Greedy method Run through your problem one step at a time, keeping track
of the single best solution at each step. Hope sincerely that this will not
lead you to make a seemingly-good choice early with bad consequences
later.
Some of these approaches work better than others—it is the role of algorithm
analysis (and experiments with real computers) to figure out which are likely to
be both correct and efficient in practice. But having all of them in your toolbox
lets you try different possibilities for a given problem.
438
5.6.4 Example: Sorting
439
5.7 Bit manipulation
5.8 Persistence
When a C program exits, all of its global variables, local variables, and heap-
allocated blocks are lost. Its memory is reclaimed by the operating system,
440
erased, and handed out to other programs. So what happens if you want to keep
data around for later?
To make this problem concrete, let’s suppose we want to keep track of a hit
counter for web pages. From time to time, the user will run the command
count_hit number where number is an integer value in the range 0 to 99, say.
(A real application would probably be using urls, but let’s keep things as simple
as possible.) We want count_hit to print the number of times the page with the
given number has been hit, i.e. 1 the first time it is called, 2 the next time, etc.
Where can we store the counts so that they will survive to the next execution of
count_hit?
The simplest solution is probably to store the data in a text file. Here’s a
program that reads a file hits, increments the appropriate value, and the writes
out a new version. To reduce the chances that data is lost (say if count_hit
blows up halfway through writing the file), the new values are written to a new
file hit~, which is then renamed to hit, taking the place of the previous version.
#include <stdio.h>
#include <stdlib.h>
int
main(int argc, char **argv)
{
int c;
int i;
int counts[NUM_COUNTERS];
FILE *f;
if(argc < 2) {
fprintf(stderr, "Usage: %s number\n", argv[0]);
exit(1);
}
/* else */
c = atoi(argv[1]);
if(c < 0 || c >= NUM_COUNTERS) {
fprintf(stderr, "Counter %d not in range 0..%d\n", c, NUM_COUNTERS - 1);
exit(2);
}
441
f = fopen(COUNTER_FILE, "r");
if(f == 0) {
perror(COUNTER_FILE);
exit(3);
}
/* read them in */
for(i = 0; i < NUM_COUNTERS; i++) {
fscanf(f, "%d", &counts[i]);
}
fclose(f);
printf("%d\n", ++counts[c]);
rename(NEW_COUNTER_FILE, COUNTER_FILE);
return 0;
}
examples/persistence/textFile.c
If you want to use this, you will need to create an initial file /tmp/hit with
NUM_COUNTERS zeroes in it.
Using a simple text file like this is the easiest way to keep data around, since
you can look at the file with a text editor or other tools if you want to do things
to it. But it means that the program has to parse the file every time it runs. We
can speed things up a little bit (and simplify the code) by storing the values in
binary.
Here’s a version that stores the data as a binary file of exactly sizeof(int) * NUM_COUNTERS
bytes. It uses the stdio routines fread and fwrite to read and write the file.
These are much faster than the loops in the previous program, since they can
just slap the bytes directly into counts without processing them at all.
The program also supplies and extra flag b to fopen. This is ignored on Unix-like
machines but is needed on Windows machines to tell the operating system that
442
the file contains binary data (such files are stored differently from text files on
Windows).
#include <stdio.h>
#include <stdlib.h>
int
main(int argc, char **argv)
{
int c;
int counts[NUM_COUNTERS];
FILE *f;
if(argc < 2) {
fprintf(stderr, "Usage: %s number\n", argv[0]);
exit(1);
}
/* else */
c = atoi(argv[1]);
if(c < 0 || c >= NUM_COUNTERS) {
fprintf(stderr, "Counter %d not in range 0..%d\n", c, NUM_COUNTERS - 1);
exit(2);
}
f = fopen(COUNTER_FILE, "rb");
if(f == 0) {
perror(COUNTER_FILE);
exit(3);
}
/* read them in */
fread(counts, sizeof(*counts), NUM_COUNTERS, f);
fclose(f);
printf("%d\n", ++counts[c]);
443
rename(NEW_COUNTER_FILE, COUNTER_FILE);
return 0;
}
examples/persistence/binaryFile.c
Again, you’ll have to initialize /tmp/hit to use this; in this case, you want it to
contain exactly 400 null characters. On a Linux machine you can do this with
the command dd if=/dev/zero of=/tmp/hit bs=400 count=1.
The advantage of using binary files is that reading and writing them is both
simpler and faster. The disadvantages are (a) you can’t look at or update the
binary data with your favorite text editor any more, and (b) the file may no
longer be portable from one machine to another, if the different machines have
different endianness or different values of sizeof(int). The second problem we
can deal with by converting the data to a standard word size and byte order
before storing it, but then we lose some advantages of speed.
We still may run into speed problems if NUM_COUNTERS is huge. The next program
avoids rewriting the entire file just to update one value inside it. This program
uses the fseek function to position the cursor inside the file. It opens the file
using the "r+b" flag to fopen, which means to open an existing binary file for
reading and writing.
#include <stdio.h>
#include <stdlib.h>
int
main(int argc, char **argv)
{
int c;
int count;
FILE *f;
if(argc < 2) {
fprintf(stderr, "Usage: %s number\n", argv[0]);
exit(1);
}
/* else */
c = atoi(argv[1]);
444
if(c < 0 || c >= NUM_COUNTERS) {
fprintf(stderr, "Counter %d not in range 0..%d\n", c, NUM_COUNTERS - 1);
exit(2);
}
f = fopen(COUNTER_FILE, "r+b");
if(f == 0) {
perror(COUNTER_FILE);
exit(3);
}
/* read counter */
fseek(f, sizeof(int) * c, SEEK_SET);
fread(&count, sizeof(int), 1, f);
printf("%d\n", ++count);
/* write it back */
fseek(f, sizeof(int) * c, SEEK_SET);
fwrite(&count, sizeof(int), 1, f);
fclose(f);
return 0;
}
examples/persistence/binaryFileFseek.c
Note that this program is not only shorter than the last one, but it also avoids
allocating the counts array. It also is less likely to run into trouble with running
out of space during writing. If we ignore issues of concurrency, this is the best
we can probably do with just stdio.
We can do even better using the mmap routine, available in all POSIX-compliant
C libraries. POSIX, which is short for Portable Standard Unix, is supported by
essentially all Unix-like operating systems and NT-based versions of Microsoft
Windows. The mmap routine tells the operating system to “map” a file in the
filesystem to a region in the process’s address space. Reading bytes from this
region will read from the file; writing bytes to this region will write to the file
(although perhaps not immediately). Even better, if more than one process
calls mmap on the same file at once, they will share the memory region, so that
updates made by one process will be seen immediately by the others (with some
caveats having to do with how concurrent access to memory actually works on
real machines).
445
Here is the program using mmap:
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/mman.h> /* For mmap. I think mman is short for "memory management." */
int
main(int argc, char **argv)
{
int c;
int *counts;
int fd;
if(argc < 2) {
fprintf(stderr, "Usage: %s number\n", argv[0]);
exit(1);
}
/* else */
c = atoi(argv[1]);
if(c < 0 || c >= NUM_COUNTERS) {
fprintf(stderr, "Counter %d not in range 0..%d\n", c, NUM_COUNTERS - 1);
exit(2);
}
if(counts == 0) {
perror(COUNTER_FILE);
exit(4);
}
printf("%d\n", ++counts[c]);
446
/* unmap the region and close the file just to be safe */
munmap(counts, sizeof(*counts) * NUM_COUNTERS);
close(fd);
return 0;
}
examples/persistence/binaryFileMmap.c
Now the code for actually incrementing counts[c] and writing it to the file
is trivial. Unfortunately, we have left stdio behind, and have to deal with
low-level POSIX calls like open and close to get at the file. Still, this may be
the most efficient version we can do, and becomes even better if we plan to do
many updates to the same file, since we can just keep the file open.
All of the solutions described so far can fail if you run two copies of count_hits
simultaneously. The mmap solution is probably the least vulnerable to failures,
as the worst that can happen is that some update is lost if the same locations is
updated at exactly the same time. The other solutions can fail more spectacularly;
simultaneous writes to /tmp/hit~ in the simple text file version, for example,
can produce a wide variety of forms of file corruption. For a simple web page hit
counter, this may not be a problem. If you are writing a back-end for a bank,
you probably want something less vulnerable.
Database writers aim for a property called ACIDity from the acronym ACID
= Atomicity, Consistency, Isolation, and Durability. These are defined
for a system in which the database is accessed via transactions consisting of
one or more operations. An example of a transaction might be ++counts[c],
which we can think of as consisting of two operations: reading counts[c], and
writing back counts[c]+1.
Atomicity means that either every operation in a transaction is performed or
none is. In practice, this means if the transaction fails any partial progress must
be undone.
Consistency means that at the end of a transaction the database is in a “consistent”
state. This may just mean that no data has been corrupted (e.g. in the text
data file we have exactly 100 lines and they’re all integer counts), or it may also
extend to integrity constraints enforce by the database (e.g. in a database of
airline flights, the fact that flight 2937 lands at HVN at 22:34 on 12/17 implies
that flight 2937 exists, has an assigned pilot, etc.).
Isolation says that two concurrent transactions can’t detect each other; the
partial progress of one transaction is not visible to others until the transaction
commits.
447
Durability means that the results of any committed transaction are permanent.
In practice this means there is enough information physically written to a disk
to reconstruct the transaction before the transaction finished.
How can we enforce these requirements for our hit counter? Atomicity is not
hard: if I stop a transaction after a read but before the write, no one will be the
wiser (although there is a possible problem if only half of my write succeeds).
Consistency is enforced by the fseek and mmap solutions, since they can’t change
the structure of the file. Isolation is not provided by any of our solutions,
and would require some sort of locking (e.g. using flock) to make sure that
only one program uses the file at a time. Durability is enforced by not having
count_hits return until the fclose or close operation has succeeded (although
full durability would require running fsync or msync to actually guarantee data
was written to disk).
Though it would be possible to provide full ACIDity with enough work, this is
a situation where using an existing well-debugged tool beats writing our own.
Depending on what we are allowed to do to the machine our program is running
on, we have many options for getting much better handling of concurrency. Some
standard tools we could use are:
• gdbm. This is a minimal hash-table-on-disk library that uses simplistic
locking to get isolation. The advantage of this system is that it’s probably
already installed on any Linux machine. The disadvantage is that it doesn’t
provide much functionality beyond basic transactions.
• Berkeley DB is a fancier hash-table-on-disk library that provides full
ACIDity but not much else. There is a good chance that some version of
this is also installed by default on any Linux or BSD machine you run into.
• Various toy databases like SQLite or MySQL provide tools that look very
much like serious databases with easy installation and little overhead.
These are probably the solutions most people choose, especially since
MySQL is integrated tightly with PHP and other Web-based scription
languages. Such a solution also allows other programs to access the table
without having to know a lot of details about how it is stored, because the
SQL query language hides the underlying storage format.
• Production-quality databases like PostgreSQL, SQL Server, or Oracle
provide very high levels of robustness and concurrency at the cost of
requiring non-trivial management and possibly large licensing fees. This is
what you pick if you really are running a bank.
6 What next?
Congratulations! You now know everything there is to know about programming
in C. Now what do you do?
My recommendation would be the following: learn C++, since you know 75% of
448
it already, and you will be able to escape from some (but not all) of the annoying
limitations of C. And learn a scripting language you can be comfortable with,
for writing programs quickly where performance isn’t the main requirement.
449
can get at the internal data of an object) and inheritance (allowing one
abstract data type to be defined by extending another). You can fake
most of these things in C if you try hard enough (for example, using
function pointers), but it is always possible to muck around with internal
bits of things just because of the unlimited control C gives you over
the environment. This can quickly become dangerous in large software
projects.
C provides only limited support for avoiding namespace collisions
In a large C program, it’s impossible to guarantee that my
eat_leftovers function exported from leftovers.c doesn’t con-
flict with your eat_leftovers function in cannibalism.c. A mediocre
solution is to use longer names: leftovers_eat_leftovers vs
cannibalism_eat_leftovers, and one can also play games with
function pointers and global struct variables to allow something like
leftovers.eat_leftovers vs cannibalism.eat_leftovers. Most
modern programming languages provide an explicit package or namespace
mechanism to allow the programmer to control who sees what names
where.
On the above list, C++ fixes everything except the missing garbage collector.
If you want to learn C++, you should get a copy of The C++ Programming
Language, by Bjarne Stroustrup, which is the definitive reference manual. But
you can get a taste of it from several on-line tutorials:
• C++ tutorial for C users, by Eric Brasseur. Exactly what it says. Intro-
duces C++ features not found in C in order of increasing complexity.
• Some other on-line tutorials that assume little or no prior programming
experience:
– http://www.cplusplus.com/doc/tutorial/
– http://www.cprogramming.com/tutorial.html
C syntax has become the default for new programming languages targeted at a
general audience. Some noteworthy examples of C-like languages are Java (used
in Android), Objective-C (used in OSX and iOS), and C# (used in Windows).
Each of these fix some of the misfeatures of C (including the lack of a garbage
collector and bounds checks on arrays) while retaining much of the flavor of
C. Which to choose probably depends on what platform you are interested in
developing for.
450
6.4 Scripting languages
/* Palindrome detector.
*
* For each line of the input, prints PALINDROME if it is a palindrome
* or the index of the first non-matching character otherwise.
*
* Note: does not handle lines containing nulls.
*/
451
int c;
size = 1;
line = malloc(size);
if(line == 0) return 0;
n = 0;
n = strlen(s);
452
return IS_PALINDROME;
}
int
main(int argc, char **argv)
{
char *line;
int mismatch;
while((line = getLine()) != 0) {
mismatch = testPalindrome(line);
if(mismatch == IS_PALINDROME) {
puts("PALINDROME");
} else {
printf("%d\n", mismatch);
}
free(line);
}
return 0;
}
examples/scripting/palindrome.c
This version is written in Perl (http://www.perl.org):
#!/usr/bin/perl
while(<>) {
chomp; # remove trailing newline
if($_ eq reverse $_) {
print "PALINDROME\n";
} else {
for $i (0..length($_) - 1) {
if(substr($_, $i, 1) ne substr($_, length($_) - $i - 1, 1)) {
print $i, "\n";
last;
}
}
}
}
453
examples/scripting/palindrome.pl
The things to notice about Perl is that the syntax is deliberately very close to
C (with some idiosyncratic extensions like putting $ on the front of all variable
names), and that common tasks like reading all input lines get hidden inside
default constructions like while(<>) and the $_ variable that functions with no
arguments like chomp operate on by default. This can allow for very compact
but sometimes very incomprehensible code.
Here’s a version in Python (https://www.python.org/):
#!/usr/bin/python
import sys
C 0.107s
Perl 0.580s
Python 2.052s
Note that for Perl and Python some of the cost is the time to start the interpreter
454
and parse the script, but factors of 10–100 are not unusual slowdowns when
moving from C to a scripting language. The selling point of these languages
is that in many applications run time is not as critical as ease and speed of
implementation.
As an even shorter example, if you just want to print all the palindromes in a
file, you can do that from the command line in one line of Perl, e.g:
$ perl -ne 'chomp; print $_, "\n" if($_ eq reverse $_)' < /usr/share/dict/words
7 Assignments
Make sure that you sign up for an account on the Zoo at http://zoo.cs.yale.edu/
accounts.html. If you already have an account, you still need to check the CPSC
223 box so that you can turn in assignments. It’s best to do this as soon as
possible.
You do not need to develop your solution on the Zoo, but you will need to turn
it in there, and it will be tested using the compiler on the Zoo.
455
Below is an example of encoding a famous Napoleonic palindrome using this
cipher:
Plaintext: A b l e w a s I e r e I s a w E l b a
Offset: 17 22 25 2 5 8 11 14 19 22 25 2 7 10 13 16 21 24 1
Ciphertext: R x k g b i d W x n d K z k j U g z b
For this assignment, you are to write a program encode.c that takes a plaintext
from stdin, encodes it using the above algorithm, and writes the result to
stdout.
For example, given the input
"Stop, thief!" cried Tom, arrestingly.
7.1.4 Hints
• You should assume that you are using the standard Latin 26-letter alphabet.
• You may assume that the characters 'A' through 'Z' and 'a' through 'z'
are represented using continuous ranges of integers, so that the expression
c - 'A' gives the position of c in the alphabet, provided c is an uppercase
character, and counting A as 0. This means that your program will not
be portable to machines that use EBCDIC or some other exotic character
representation.
• To test if a character is uppercase or lowercase, one option would be to put
#include <ctype.h> in your program and use the isupper and islower
macros. Note that these may behave oddly if you have set a locale that
uses a different alphabet. It may be safer to make your own tests.
456
$ ./encode < test.in > tmp
$ cmp tmp test.out
If tmp and test.out contain the same characters, cmp will say nothing. Other-
wise it will tell you the first position where they differ.
If you want to see what characters are in a binary file, trying using od -t x1z,
as in
$ echo hi > file
$ cat file
hi
$ od -t x1z file
0000000 68 69 0a >hi.<
0000003
/*
* Encode text on stdin by alphabet rotation with shifting offset.
*
* Initially, each character 'A'..'Z' or 'a'..'z' is rotated 17 positions.
*
* After encoding an uppercase letter, the offset is increased by 5 (mod 26).
457
*
* After encoding a lowercase letter, the offset is increased by 3 (mod 26).
*
* These parameters are set using the INITIAL_OFFSET, UPPERCASE_STEP, and LOWERCASE_STEP
* constants defined below.
*
*/
#include <stdio.h>
int
main(int argc, char **argv)
{
int offset = INITIAL_OFFSET;
int c;
return 0;
}
examples/2015/hw/1/encode.c
458
speed while still protecting your valuable loot. This interface is defined
in the following file, which can also be found on the Zoo in the directory
/c/cs223/Hwk2/sourceFiles:
/*
* API for safes made by the
* Hollywood Hackable Safe Company LLC.
*/
/*
* Returns the number of tumblers on a safe.
* If this is n, the possible tumbler indices will be 0 through n-1.
* */
int numTumblers(Safe *s);
/*
* Returns the number of positions of each tumbler.
* If this is n, the possible tumbler positions will be 0 through n-1.
*/
int numPositions(Safe *s);
/*
* Try a combination.
*
* This should be an array of numTumbler(s) ints.
*
* Returns contents of safe (a non-negative int) if combination is correct
* and safe has not yet self-destructed.
*
* Returns SAFE_BAD_COMBINATION if combination is incorrect
* and safe has not yet self-destructed.
*
* Returns SAFE_SELF_DESTRUCTED if safe has self-destructed.
*
* Note: may modify combination.
*/
int tryCombination(Safe *s, int *combination);
examples/2015/hw/2/safe.h
The noteworthy function in this API is tryCombination, which takes a pointer
459
to a safe and an array of ints representing the combination, and returns either
the contents of the safe (an int), the special code SAFE_BAD_COMBINATION if the
combination is incorrect, or the special code SAFE_SELF_DESTRUCTED if the safe
blew up after seeing too many bad combinations. Note that tryCombination
does not declare its second argument to be const and may not leave it intact.
The additional functions allow you to obtain important information about the
safe, like how many tumblers it has and what values these tumblers can be set
to. The behavior of a safe given a combination with the wrong number of values
or values outside the permitted range is undefined.
Your task is to write a function openSafe that will open a safe, if possible, by
trying all possible combinations. Note that if the safe self-destructs before you
can try all the possibilities, this task may not in fact be possible. Your openSafe
function should return SAFE_SELF_DESTRUCTED in this case. Your function
should be defined in a file openSafe.c and should match the declaration in this
file:
/* Include safe.h before this file to get the definition of Safe. */
/*
* Open a safe and return the value returned by tryCombination,
* or SAFE_SELF_DESTRUCTED if the safe self-destructed.
*/
int openSafe(Safe *s);
examples/2015/hw/2/openSafe.h
It is recommended that you put the lines below in your openSafe.c file to ensure
consistency with these declarations:
#include "safe.h"
#include "openSafe.h"
You may put additional functions in openSafe.c if that would be helpful. You
should declare these static to avoid the possibility of namespace conflicts.
In addition to safe.h and openSafe.h, /c/cs223/Hwk2/sourceFiles also con-
tains a main.c file that can be compiled together with openSafe.c to generate a
program that can be called from the command line. This program generates a
safe with a pseudorandom combination based on parameters specified on the
command line, runs your openSafe routine on it, and prints the value that
openSafe returns. You should not rely on your function being tested with this
particular program.
460
You do not need to submit any other files (and the test script will ignore them
if you do).
You can test that your program compiles and passes a few basic tests with the
command
/c/cs223/bin/testit 2 openSafe
This runs the test script in /c/cs223/Hwk2/test.openSafe on your submit-
ted assignment. You can also run this script by hand to test the version of
openSafe.c in your current working directory.
7.2.3 Valgrind
You may need to allocate storage using malloc to complete this assignment. If
you do so, you should make sure that you call free on any block you allocate
inside your openSafe function before the function returns. The test.openSafe
script attempts to detect storage leaks or other problems resulting from misuse of
these routines by running your program with valgrind. You can also use valgrind
yourself to track down the source of errors, particularly if you remember to
compile with debugging info turned on using the -g3 option to gcc. The script
/c/cs223/bin/vg gives a shortcut for running valgrind with some of the more
useful options.
#include <stdlib.h>
#include <assert.h>
#include "safe.h"
#include "openSafe.h"
461
{
int *copy; /* duplicate of combination */
int result; /* result of tryCombination */
int n; /* number of tumblers */
int i;
n = numTumblers(s);
free(copy);
return result;
}
int
openSafe(Safe *s)
{
int *combination; /* counter for combinations */
int n; /* number of tumblers */
int base; /* number of positions */
int result; /* result of tryCombination */
/* allocate space */
n = numTumblers(s);
462
base = numPositions(s);
for(zeroCombination(n, combination);
(result = nondestructiveTryCombination(s, combination)) == SAFE_BAD_COMBINATION;
nextCombination(n, base, combination));
free(combination);
return result;
}
examples/2015/hw/2/openSafe.c
i c0 + c1 i + c2 i2
0 1=1+5·0+3·0
1 9 = 1 + 5 · 1 + 3 · 12
2 23 = 1 + 5 · 2 + 3 · 22
Similarly, we can use quadratic letter sequences to reveal secret messages hidden
in the lyrics of K-pop songs:
$ ./qls hail satan < gangnam-style-excerpt.txt
470 3 5 hail
14 10 30 satan
14 56 7 satan
or even examine Act 1 of The Tempest to help resolve the Shakespeare authorship
question:27
27 Stratfordians, Oxfordians, and other conspiracy theorists might object that these results
depend critically on the precise formatting of the text. We counter this objection by observing
that we used the Project Gutenberg e-text of The Tempest, which, while not necessarily the
463
$ ./qls "Bacon" "de Vere" "Marlowe" "Stanley" "that Stratford dude" < tempest-act-one.txt
120 387 777 Bacon
120 542 906 Bacon
120 851 850 Bacon
120 1592 726 Bacon
120 1607 472 Bacon
120 2461 95 Bacon
120 2729 50 Bacon
120 3225 215 Bacon
120 3420 284 Bacon
120 4223 330 Bacon
120 4534 76 Bacon
120 5803 29 Bacon
143 46 161 Bacon
143 268 727 Bacon
143 684 1434 Bacon
[... 280 more lines of Bacon omitted ...]
19959 1178 87 Bacon
5949 239 465 Marlowe
Write a program qls.c that takes a text on stdin and searches for quadratic
letter sequences that start with the strings given in argv. Your program should
output all such quadratic letter sequences that it finds, using the format
printf("%d %d %d %s\n", [...]);
where [...] should be replaced by appropriate expressions to give c0 , c1 , c2 ,
and the string found.
If a string appears more than once at the start of a quadratic letter sequence,
your program should print all occurrences. The order your output lines appear
in is not important, since the test script sorts them into a canonical order. Do
whatever is convenient.
Your program should be reasonably efficient, but you do not need to get carried
away looking for a sophisticated algorithm for this problem. Simply testing all
plausible combinations of coefficients should be enough.
Because neither K-pop songs nor Elizabethan plays use null characters, you may
assume that no null characters appear in your input.
most favored by academic Shakespeare scholars, is the easiest version to obtain on-line. We
consider it further evidence of Sir Francis Bacon’s genius that not only was he able to subtly
encode his name throughout his many brilliant plays, but he was even able to anticipate the
effects of modern spelling and punctuation on this encoding.
464
You may also assume that any search strings will contain at least two characters,
in order to keep the number of outputs finite.
/*
* Search for quadratic letter sequences starting with words from argv on stdin.
*
* A quadratic letter sequence of length n in s is a sequence of characters
*
* s[c0 + c1*i + c2*i*i]
*
* where c0, c1, c2 are all >= 0, at least one of c1 and c2 is > 0,
* and i ranges over 0, 1, 2, ..., n-1.
*
* For each QLS found, prints c0, c1, c2, and the target string to stdout.
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <assert.h>
/*
* Return true iff we get a match in s for t with coefficients c
*
465
* Behavior is undefined if coefficients would send us off the end of s.
*/
static int
qlsMatch(const char *s, const char *t, int c[NUM_COEFFICIENTS])
{
int i;
return 1;
}
/*
* Search for quadratic letter sequences in s starting with t
* and print results to stdout.
*/
static void
qlsSearch(const char *s, const char *t)
{
int c[NUM_COEFFICIENTS]; /* coefficients */
int lenS; /* length of s */
int lenT; /* length of t */
int maxI; /* maximum value for i (this is lenT-1) */
lenS = strlen(s);
lenT = strlen(t);
maxI = lenT-1;
/* try all possible c[0] that will let us finish before lenS */
for(c[0] = 0; c[0] + maxI < lenS; c[0]++) {
/* if s[c[0]] isn't right, c[1] and c[2] can't fix it */
if(s[c[0]] == t[0]) {
/* try all feasible c[1] */
for(c[1] = 0; c[0] + c[1] * maxI < lenS; c[1]++) {
/* try all feasible c[2], but start at 1 if c[1] == 0 */
for(c[2] = (c[1] == 0); c[0] + c[1] * maxI + c[2] * maxI * maxI < lenS; c[2]
/* now see if we get a match */
if(qlsMatch(s, t, c)) {
printf("%d %d %d %s\n", c[0], c[1], c[2], t);
}
}
466
}
}
}
}
/*
* Return a single string holding all characters from stdin.
*
* This is malloc'd data that the caller should eventually free.
*/
static char *
getContents(void)
{
size_t size;
size_t len;
char *text;
int c;
size = INITIAL_BUFFER_SIZE;
len = 0;
text = malloc(size);
assert(text);
text[len++] = c;
}
/* cleanup */
text = realloc(text, len+1);
assert(text);
text[len] = '\0';
return text;
}
467
int
main(int argc, char **argv)
{
int i;
char *s;
s = getContents();
free(s);
return 0;
}
examples/2015/hw/3/qls.c
For this assignment you are to write a program that takes from stdin a sequence
of instructions for pasting ASCII art pictures together, reads those pictures from
files, and writes the combined picture to stdout.
Each instruction is of the form row column filename, suitable for reading
with scanf("%d %d %s", &row, &col, filename);, where row and col are
declared as ints and filename is a suitably large buffer of chars. Such an
instruction means to paste the contents of file filename into the picture with
each character shifted row rows down and column columns to the right of its
position in file filename. When pasting an image, all characters other than space
(' ', or ASCII code 32) overwrite any characters from earlier files at the same
position. Spaces should be treated as transparent, having no effect on the final
image.
For example, suppose that the current directory contains these files:
# # #
\==========/
\......../
examples/2015/hw/4/ship
/\
468
/vv\
/vvvv\
||
examples/2015/hw/4/tree
* * *
____|_|_|_____
|_____________|
|___HAPPY_____|
|__BIRTHDAY___|
|_____________|
examples/2015/hw/4/cake
Then this is what we should get from executing the command:
$ echo "1 1 ship 3 5 ship 3 19 tree 7 2 ship 13 4 ship 4 22 tree 5 6 cake" | ./compositor
# # #
\==========/
\......#.# # /\
\==========/ /vv\/\
\....*.*.* /vvv/vv\
____|_|_|_____|/vvvv\
|_____________| ||
\===|___HAPPY_____|
\..|__BIRTHDAY___|
|_____________|
# # #
\==========/
\......../
examples/2015/hw/4/example.out
For this assignment, you may submit whatever source files you like, along with
a file Makefile that will generate the program compositor when make is called
with no arguments (see the instructions for using make.)
You can test your submitted assignment using the public test script with
/c/cs223/bin/testit 4 public
You may also test your unsubmitted assignment in the current working directory
with
469
/c/cs223/Hwk4/test.public
The test script is intended mostly to guard against trivial errors in output format
and is not necessarily exhaustive.
7.4.3 Notes
7.4.3.1 Input
For parsing the commands on stdin, we recommend using scanf. You can test
for end of file by checking if scanf correctly parsed all three arguments, as in
int row;
int col;
char filename[BUFFER_SIZE];
7.4.3.2 Output
Your output should include newline and space characters to put the composited
characters in the appropriate rows and columns. It should not include any more
of such characters than are absolutely necessary.
For example, there should never be a space at the end of a line (even if there
is a space at the end of a line in one of the input files). Similarly, there should
not be any blank lines at the end of your output. You may, however, find it
necessary to add a newline to the end of the last line to avoid having the output
end in the middle of a line.
7.4.3.3 General
You may assume that the final picture is not so big that you can’t store a row
or column number for one of its characters in an int.
28 Normally this is a dangerous thing to assume, but this assignment is complicated enough
already.
470
7.4.4 Sample solution
I wrote two versions of this. The first used a jagged array to represent an image,
but I decided I didn’t like it and did another version using a sorted linked list of
points. This second version is shown below.
/*
* Alternate version of ASCII art thing using a queue.
*/
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
/*
* Idea of this data structure is that we have a sorted array
* of pixels, where each pixel specifies a row, column, and character
* to put in that position. The sort order is row then column.
*
* This is organized as a queue in the sense that we can push
* new pixels on to the end of it, although as it happens we
* never actually dequeue anything.
*/
struct pixel {
int row;
int col;
char value;
};
struct queue {
size_t top; /* number of elements */
size_t size; /* number of allocated slots */
struct pixel *pixels; /* pixel values, sorted by row then column */
};
q = malloc(sizeof(struct queue));
assert(q);
471
q->top = 0;
q->size = QUEUE_INITIAL_SIZE;
return q;
}
/* clean up queue */
void
queueDestroy(struct queue *q)
{
free(q->pixels);
free(q);
}
q->pixels[q->top++] = p;
}
q = queueCreate();
f = fopen(filename, "r");
if(f == 0) {
perror(filename);
exit(1);
}
472
p.row = p.col = 0;
fclose(f);
return q;
}
473
/* end last row */
putchar('\n');
}
/*
* Merge two queues, creating a new, freshly-allocated queue.
* New queue is sorted. If there are pixels in both left
* and right with the same row and column, the one from right
* overwrites the one from left.
*/
struct queue *
queueMerge(const struct queue *left, const struct queue *right)
{
int l = 0;
int r = 0;
struct queue *q;
q = queueCreate();
474
queuePush(q, right->pixels[r++]);
}
return q;
}
int
main(int argc, char **argv)
{
struct queue *merged; /* holding place for result of merge */
struct queue *left; /* accumulated picture */
struct queue *right; /* new picture */
int row; /* row offset for new picture */
int col; /* column offset for new picture */
char filename[BUFFER_SIZE]; /* filename for new picture */
if(argc != 1) {
fprintf(stderr, "Usage: %s\n", argv[0]);
return 1;
}
queueDestroy(left);
queueDestroy(right);
}
475
queueWrite(left);
queueDestroy(left);
return 0;
}
examples/2015/hw/4/compositor.c
Here is a Makefile.
476
You may assume that the program is argv is complete in the sense that it
includes rules for any combination of state and symbol you will encounter while
executing it. You are not required to detect if this assumption is violated.
7.5.2 Example
The program
b+2a-0 a-1a-1
gives instructions for what to do in state 1 (b+2a-0) and state 2 (a-1a-1). In
state 1, if the controller reads an a, the triple b+2 means that it should write
b, move right (+), and switch to state 2. If instead it reads a b, the triple a-0
means that it should write a, move left (-), and halt (0). In state 2, the machine
always writes a, moves left, and switches to state 1.
Below is a depiction of this machine’s execution. It passes through 4 states
(including both the initial state and the final halting state) using a total of 3
steps. The controller and its current state is shown above its current position on
the tape at each point in time. To avoid having to put in infinitely long lines,
only the middle three tape cells are shown.
1
aaa
2
aba
1
aba
0
aaa
You should submit a Makefile and whatever source files are needed to generate a
program ./turing when make is called with no arguments. The turing program
should simulate a Turing machine as described above and print the number of
steps that it takes until it halts in decimal format, followed by a newline. It
should not produce any other output. For example, using the program above,
your program should print 3:
$ ./turing b+2a-0 a-1a-1
3
477
For more complex programs you may get different results. Here is a 3 state, 3
symbol program that runs for a bit longer:
$ ./turing b+2a-0c-3 b-3c+2b-2 b-1a+2c-1
92649163
You may assume that tape symbols can always be represented by lowercase
letters, that states can always be represented by single digits, and that argv is
in the correct format (although it may be worth including a few sanity checks in
your program just in case).
Not all Turing machine programs will halt. Your program is not required to
detect if the Turing machine it is simulating will halt eventually or not (although
it should notice if it does halt).
Submit all files needed to build your program as usual using /c/cs223/bin/submit
5 filename.
There is a public test script in /c/cs223/Hwk5/test.public. You can run this
on your submitted files with /c/cs223/bin/testit 5 public.
/*
* Simple Turing machine simulator.
*
* Tape holds symbols 0 (default) through 2.
*
* Controller programming is specified in argv:
*
* argv[i] gives transitions for state i as six characters.
*
* Each triple of characters is <action><direction><new-state>
*
* where <action> is one of:
*
* a,b,c: write this value to tape
*
* <direction> is one of:
*
* -: go left
* +: go right
* .: stay put
*
478
* The three pairs give the transition for reading 0, 1, 2 from tape.
*
* State 0 is the halting state.
*
* On halting, prints number of transitions followed by contents
* of all tape cells that have ever been visited by the
* finite-state controller.
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <assert.h>
#include <sys/types.h>
struct configuration {
unsigned int state;/* state of head */
size_t leftmost; /* leftmost cell visited */
size_t rightmost; /* rightmost cell visited */
size_t current; /* current cell */
size_t tapeLength; /* current allocated space for tape */
char *tape; /* contents of cells */
};
newTapeLength = 4*c->tapeLength;
newTape = malloc(newTapeLength);
assert(newTape);
479
newTape[i + offset] = c->tape[i];
}
oldTape = c->tape;
c->tape = newTape;
c->tapeLength = newTapeLength;
c->current += offset;
c->leftmost += offset;
c->rightmost += offset;
free(oldTape);
}
struct configuration *
configurationCreate(void)
{
struct configuration *c;
size_t i;
c = malloc(sizeof(struct configuration));
assert(c);
c->state = 1;
c->tapeLength = INITIAL_TAPE_LENGTH;
c->leftmost = c->rightmost = c->current = c->tapeLength / 2;
c->tape = malloc(c->tapeLength);
assert(c->tape);
return c;
}
void
configurationDestroy(struct configuration *c)
{
free(c->tape);
free(c);
}
480
/* used for debugging mostly */
void
configurationPrint(const struct configuration *c)
{
size_t i;
int
main(int argc, char **argv)
{
struct configuration *c;
char cellValue;
const char *transition;
size_t steps;
if(argc == 1) {
fprintf(stderr, "Usage: %s transitions\n", argv[0]);
return 1;
}
c = configurationCreate();
steps = 0;
while(c->state != 0) {
steps++;
cellValue = c->tape[c->current];
assert(0 <= cellValue);
assert(3*(cellValue+1) <= strlen(argv[c->state]));
481
c->tape[c->current] = transition[0] - SYMBOL_BASE;
switch(transition[1]) {
case '-':
if(c->current == 0) {
configurationExpand(c);
}
c->current--;
if(c->current < c->leftmost) {
c->leftmost = c->current;
}
break;
case '+':
if(c->current == c->tapeLength - 1) {
configurationExpand(c);
}
c->current++;
if(c->current > c->rightmost) {
c->rightmost = c->current;
}
break;
case '.':
/* do nothing */
break;
default:
fprintf(stderr, "Bad direction '%c'\n", transition[2]);
exit(2);
break;
}
#ifdef PRINT_CONFIGURATION
configurationPrint(c);
#endif
}
configurationDestroy(c);
return 0;
}
482
examples/2015/hw/5/turing.c
CC=gcc
CFLAGS=-std=c99 -Wall -pedantic -g3
all: turing
compositor: turing.o
$(CC) $(CFLAGS) -o $@ $^
clean:
$(RM) turing *.o
examples/2015/hw/5/Makefile
For this assignment, you are to implement a data structure for playing a game
involving ships placed in a large square grid. Each ship occupies one more more
squares in either a vertical or horizontal line, and has a name that consists of a
single char other than a period (which will be used to report the absence of a
ship). Ships have a bounded maximum length; attempts to place ships longer
than this length have no effect.
All type and constant definitions for the data type, and all function declarations,
are given in the file ships.h, which is shown below, and which you can also find
in /c/cs223/Hwk6/sourceFiles/ships.h. The playing field is represented by
a struct field (which you get to define). A new struct field is created by
fieldCreate, and when no longer needed should be destroyed by fieldDestroy.
These data types from ships.h control ship naming and placement. Note that
uint32_t is defined in stdint.h (which is also included by inttypes.h. You
will need to include one of these files before ships.h to get this definition.
typedef uint32_t coord;
struct position {
coord x;
coord y;
};
struct ship {
struct position topLeft; /* coordinates of top left corner */
int direction; /* HORIZONTAL or VERTICAL */
unsigned int length; /* length of ship */
483
char name; /* name of ship */
};
Actual placement is done using the fieldPlaceShip function, declared as follows:
void fieldPlaceShip(struct field *f, struct ship s);
A ship of length m placed horizontally with its top left corner at position (x, y)
will occupy positions (x, y) through (x+m−1, y). If instead it is placed vertically,
it will occupy positions (x, y) through (x, y + m − 1). If any of these coordinates
exceed the maximum coordinate COORD_MAX (defined in ships.h), the ship will
not be placed. The ship will also not be placed if its name field is equal to
NO_SHIP_NAME or if the length exceeds MAX_SHIP_LENGTH.
If the new ship will occupy any position as a ship previously placed in the field,
the previous ship will be removed. It is possible for many ships to be removed
at once in this way.
The fieldAttack function can be used to remove a ship at a particular location
without placing a new ship. It returns the name of the removed ship, if any, or
NO_SHIP_NAME if there is no ship at that location.
Finally, the fieldCountShips returns the number of ships still present in the
field.
Your job is to write an implementation of these functions, which you should
probably put in a file ships.c. You must also supply a Makefile, which,
when make is called with no arguments, generates a test program testShips
from your implementation and the file testShips.c that we will provide. You
should not count on precisely this version of testShips.c being supplied; your
implementation should work with any main program that respects the interface
in ships.h.
You should write your implementation so that it will continue to work if the
typedef for coord, or the definitions of the constants COORD_MAX, NO_SHIP_NAME,
SHIP_MAX_LENGTH, HORIZONTAL, or VERTICAL change. You may, however, assume
that coord is an unsigned integer type and the COORD_MAX is the largest value
that can be represented by this type.
If it helps in crafting your implementation, you may assume that
MAX_SHIP_LENGTH will alway be a reasonably small constant. You do
not need to worry about implementing a data structure that will handle huge
ships efficiently. On the other hand, COORD_MAX as defined in the default
ships.h is 23 2 − 1, so you will need to be able to deal with a field with at
least 26 4 possible locations, a consideration you should take into account when
choosing a data structure to represent a field.
484
7.6.3 The testShips program
485
...c.
...c.
...c.
.....
.....
The input files used by test.public can be found in /c/cs223/Hwk6/testFiles.
Some of these were generated randomly using the script /c/cs223/Hwk6/makeRandom,
which you should feel free to use for your own nefarious purposes.
Because the interface in ships.h gives no way to find out what ships are currently
in the field, the test program will not actually produce pictures like the above.
Instead, it prints after each command a line giving the name of the ship sunken by
fieldAttack (or NO_SHIP_NAME if no ship is sunk or fieldPlaceShip is called)
and the number of ships left in the field following the attack. So the user must
imagine the carnage as the 100000 ships in randomSparseBig.in somehow leave
only 25336 survivors in randomSparseBig.out, demonstrating the importance
of strict navigational rules in real life.
486
7.6.4 Submitting your assignment
/*
* Type for coordinates, and their maximum possible value.
*
* Include <stdint.h> before this header file
* to get the definition of uint32_t
* and its maximum value UINT32_MAX.
*/
typedef uint32_t coord;
#define COORD_MAX (UINT32_MAX)
/*
* Non-opaque structs for passing around positions and ship placements.
*/
struct position {
coord x;
coord y;
};
struct ship {
struct position topLeft; /* coordinates of top left corner */
int direction; /* HORIZONTAL or VERTICAL */
unsigned int length; /* length of ship */
char name; /* name of ship */
};
/*
487
* Create a playing field for holding ships.
*/
struct field *fieldCreate(void);
/*
* Free all space associated with a field.
*/
void fieldDestroy(struct field *);
/*
* Place a ship in a field with given placement and name.
*
* If placement.length is less than one or greater than MAX_SHIP_LENGTH,
* or if some part of the ship would have a coordinate greater than COORD_MAX,
* or if the ship's name is NO_SHIP_NAME,
* the function returns without placing a ship.
*
* Placing a new ship that intersects any previously-placed ships
* sinks the previous ships, removing them from the field.
*/
void fieldPlaceShip(struct field *f, struct ship s);
/*
* Attack!
*
* Drop a shell at given position.
*
* Returns NO_SHIP_NAME if attack misses (does not intersect any ship).
*
* Otherwise returns name of ship hit.
*
* Hitting a ship sinks it, removing it from the field.
*/
char fieldAttack(struct field *f, struct position p);
/*
* Return number of ships in the field.
*/
size_t fieldCountShips(const struct field *f);
examples/2015/hw/6/ships.h
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
#include <stdint.h>
#include <inttypes.h>
488
#include "ships.h"
int
main(int argc, char **argv)
{
struct field *f; /* where we keep our ships */
int command; /* command char */
struct ship s; /* ship we are placing */
struct position p; /* location to attack */
int sank; /* ship we sank */
if(argc != 1) {
fprintf(stderr, "Usage: %s\n", argv[0]);
return 1;
}
f = fieldCreate();
fieldPlaceShip(f, s);
sank = NO_SHIP_NAME;
break;
case ATTACK:
if(scanf("%" SCNu32 " %" SCNu32 " ", &p.x, &p.y) != 2) {
fprintf(stderr, "Not enough enough args to %c\n", ATTACK);
return 1;
}
/* else */
489
sank = fieldAttack(f, p);
break;
default:
/* bad command */
fprintf(stderr, "Bad command %c\n", command);
return 1;
break;
}
fieldDestroy(f);
return 0;
}
examples/2015/hw/6/testShips.c
#include <stdlib.h>
#include <assert.h>
#include <string.h>
#include <stdint.h>
#include "ships.h"
struct elt {
struct elt *next; /* pointer to next element in linked list */
struct ship ship; /* ship in this element */
};
490
static size_t
hash(struct position p)
{
return X_HASH_FACTOR * p.x + Y_HASH_FACTOR * p.y;
}
f = malloc(sizeof(struct field));
assert(f);
f->size = initialSize;
f->occupancy = 0;
return f;
}
struct field *
fieldCreate(void)
{
return fieldCreateInternal(DEFAULT_INITIAL_SIZE);
}
491
for(e = f->table[i]; e != 0; e = next) {
next = e->next;
free(e);
}
}
free(f->table);
}
void
fieldDestroy(struct field *f)
{
fieldDestroyContents(f);
free(f);
}
/*
* Helper for fieldPlaceShip.
*
* This skips all the sanity-checking in fieldPlaceShip,
* and just performs the hash table insertion.
*/
static void
fieldInsertShip(struct field *f, struct ship s)
{
size_t h; /* hashed coordinates */
struct elt *e; /* new element to insert */
h = hash(s.topLeft) % f->size;
e = malloc(sizeof(struct elt));
assert(e);
e->ship = s;
e->next = f->table[h];
f->table[h] = e;
f->occupancy++;
}
void
fieldPlaceShip(struct field *f, struct ship s)
{
492
struct field *f2;
struct elt *e;
struct position pos;
size_t i;
free(f2);
}
fieldAttack(f, pos);
493
}
/*
* Helper for fieldAttack.
*
* If there is a ship with topLeft at given position, return pointer
* to location in hash table that points to it (either table entry
* or next component).
*
* If not, return null.
*/
static struct elt **
fieldShipAt(struct field *f, struct position p)
{
struct elt **prev; /* previous pointer */
/*
* Attack!
*
* Drop a shell at given position.
*
* Returns 0 if attack misses (does not intersect any ship).
*
* Otherwise returns name of ship hit,
* which should be freed by caller when no longer needed.
*
* Hitting a ship sinks it, removing it from the field.
*/
char
fieldAttack(struct field *f, struct position p)
{
struct position p2;
494
int i;
int direction;
struct elt **prev;
struct elt *freeMe;
char name;
if(prev) {
/* if we sink anybody, it will be this ship */
/* but maybe it doesn't reach */
/* or points in the wrong direction */
if((*prev)->ship.length > i && (*prev)->ship.direction == direction) {
/* got it */
freeMe = *prev;
*prev = freeMe->next;
name = freeMe->ship.name;
free(freeMe);
f->occupancy--;
return name;
} else {
/* didn't get it */
/* maybe try again in other direction */
break;
}
}
}
}
495
/*
* Return number of ships in the field.
*/
size_t
fieldCountShips(const struct field *f)
{
return f->occupancy;
}
examples/2015/hw/6/ships.c
For this assignment you are to implement a strategy for playing a card game
involving moving cards (represented by uint64_ts) down through a sequence of
n piles. The interface to your strategy is given in the file strategy.h, shown
below:
/*
* Interface for card-playing strategy.
*
* The deal function supplies a new card to the strategy. Each possible card will only be d
*
* The play function should return a card that has been dealt previously but not yet played.
* If asked for a card when the hand is empty, its behavior is undefined.
*/
#include <stdint.h>
496
/* play a card from pile k */
Card strategyPlay(Strategy *, int k);
examples/2015/hw/7/strategy.h
Initially, the player has n piles, numbered 1 through n. The strategyDeal
function is called to indicate that a new card has been dealt to pile n. The
strategyPlay function is called to indicate that a card should be moved from
pile k to pile k-1; this function should return the card to move. Cards moved to
pile 0 leave the game and are not used again. Each card is unique: once a card is
dealt, the same card will never be dealt again during the same play of the game.
The choice of when to deal and when to play from pile is controlled by some
external entity, which at some point will stop and compute the smallest card in
each pile. The goal of the strategy is to make these smallest cards be as large as
possible, giving priority to the highest-numbered piles: given two runs of the
game, the better-scoring one is the one that has the larger smallest card in pile
n, or, if both have the same smallest card in pile n, the one that has the larger
smallest card in pile n − 1, and so forth. A tie would require that both runs end
with the same smallest card in every pile. An empty pile counts as UINT64_MAX
for this purpose (although note that a strategy has no control over which piles
are empty).
Your job is to implement a strategy that produces the best possible result
for any sequence of calls to strategyDeal and strategyPlay. Your strategy
implementation will most likely need to keep track of which cards are available in
each pile, as this information is not provided by the caller. Your strategyPlay
function should only make legal moves: that is, it should only play cards that are
actually present in the appropriate pile. You may assume that strategyPlay is
never called on an empty pile.
Your implementation should consist of a file strategy.c and any support-
ing source and header files that you need other than strategy.h, which we
have provided for you. You should also supply a file Makefile that gener-
ates a program testStrategy when make is called with no arguments, us-
ing your implementation and the testStrategy.c file that you can find in
/c/cs223/Hwk7/sourceFiles/testStrategy.c.
The testStrategy program implements one of four rules for when you can play
from each pile. The arguments to testStrategy are a character indicating which
rule to apply, the number of cards to deal (which can be pretty big), and the
number of piles (which is much more limited, because testStrategy.c tracks
the pile each card is in using a char to save space). The actual cards dealt are
generated deterministically and will be the same in every execution with the
same arguments. The test files in /c/cs223/Hwk7/testFiles give the expected
497
output when testStrategy is run with the arguments specified in the filename
(after removing the - characters); this will always be the value, in hexadecimal,
of the smallest card in each pile, starting with the top pile.
For example, running the harmonic rule h with 1000 cards and 4 piles (not
counting the 0 pile) gives the output
$ ./testStrategy h 1000 4
5462035faf0d6fa1
501ebb6268d39af3
25732b5fee7c8ad7
301e0f608d124ede
This output would appear in a filename h-1000-4, if this particular combination
of parameters were one of the test cases.
For this assignment, you are to implement an ordered set data type for holding
null-terminated strings. The interface to this data type is given in the file
orderedSet.h, shown below.
/*
* Ordered set data structure.
*/
498
struct orderedSet *orderedSetCreate(void);
/* Destroy a set */
void orderedSetDestroy(struct orderedSet *);
The test program is a fairly thin wrapper over the implementation that allows
you to call the various functions using one-line commands on standard input.
A command is given as the first character of the line, and the rest of the line
499
contains the argument to the command if needed. The + and - commands add
or remove an element from the set, respectively, while the p, s, and h commands
print the contents of the set, the size of the set, and a hash of the set (these
commands ignore any argument). The f command removes all elements of the
set that do not contain a particular substring.
Here is a simple input to the program that inserts four strings, filters out the
ones that don’t contain ee, then prints various information about the results.
+feed
+the
+bees
+please
fee
s
h
p
This should produce the output
2
15082778b3db8cb3
bees
feed
There were a lot of ways to do this. For the sample solution, I decided to do
something unusual, and store the set as a hash table. This is not ordered, but
since the only operation that requires the set to be ordered is orderedSetFilter,
which will take Ω(n) time no matter how you implement it, the O(n log n) cost
to call qsort to sort the elements as needed does not add much overhead.
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
500
#include <stdint.h>
#include <string.h>
#include "orderedSet.h"
s = malloc(sizeof(*s));
assert(s);
s->n = 0;
s->size = size;
s->table = calloc(s->size, sizeof(char *));
return s;
}
struct orderedSet *
orderedSetCreate(void)
{
return orderedSetCreateInternal(INITIAL_SIZE);
}
/* Destroy a set */
void
orderedSetDestroy(struct orderedSet *s)
{
size_t i;
501
if(s->table[i]) {
free(s->table[i]);
}
}
free(s->table);
free(s);
}
static size_t
hash(const char *s)
{
size_t h;
return h;
}
static char *
strMalloc(const char *s)
{
char *s2;
s2 = malloc(strlen(s)+1);
strcpy(s2, s);
return s2;
}
assert(elt);
502
/* skip over non-empty slots with different values */
for(h = hash(elt) % s->size; s->table[h] && strcmp(s->table[h], elt); h = (h+1) % s->siz
orderedSetInsertInternal(s, strMalloc(elt));
}
503
/* skip over non-empty slots with different values */
for(h = hash(elt) % s->size; s->table[h] && strcmp(s->table[h], elt); h = (h+1) % s->siz
/* remove and reinsert any elements up to the next hole, in case they wanted to be e
for(h = (h+1) % s->size; s->table[h] ; h = (h+1) % s->size) {
later = s->table[h];
s->table[h] = 0;
s->n--;
orderedSetInsertInternal(s, later);
}
}
}
static int
compare(const void *s1, const void *s2)
{
return strcmp(*((const char **) s1), *((const char **) s2));
}
top = 0;
504
a[top++] = s->table[h];
}
}
s2 = orderedSetCreate();
free(a);
return s2;
}
examples/2015/hw/8/orderedSet.c
Makefile{examples/2015/hw/8/Makefile}
For this problem, you are given a rectangular maze consisting of wall squares
(represented by 0) and path squares (represented by 1). Two path squares are
considered to be adjacent if they are at most one square away orthogonally or
diagonally; in chess terms, two path squares are adjacent if a king can move
from one to the other in one turn. The input to your program is a maze in which
the graph consisting of all path squares is connected and contains at most one
cycle, where a cycle is a sequence of distinct squares s1 , s2 , . . . , sk where each si
is adjacent to si+1 and sn is adjacent to s1 . Your job is to write a program maze
that finds this cycle if it exists, and marks all of its squares as cycle squares
(represented by 2).
For example, here is a picture of a 200-by-100 maze that contains a small cycle:
and here is the same maze with the cycle highlighted in white:
The input to your program should be taken from stdin, in a restricted version
of raw PGM format, an old image format designed to be particularly easy to
505
Figure 9: 200 by 100 maze
506
parse. The input file header will be a line that looks like it was generated by the
printf conversion string "P5 %d %d 255\n", where the first int value is the
width of the image in columns and the second is the height of the image in rows;
the same conversion string can be given to scanf to parse this line. Following
the newline will be a long sequence of bytes, each representing one pixel of the
image, with each row following immediately after the previous one. These bytes
will be either 0 or 1 depending on whether that position in the maze is a wall or
a path.
The output to your program should be in the same format, with the difference
that now some of the bytes in the image data may be 2, indicating the cycle.
If there is no cycle, the output should be identical to the input. Your program
is not required to detect or respond in any particular way to input mazes that
violate the format or do not contain a connected graph of path squares, although
you are encouraged to put in reasonable error checking for your own benefit
during testing.
For example, the maze depicted above is stored in the file 200-100-4.in.pgm;
the corresponding output is stored in the file 200-100-4.out.pgm. Other sample
inputs and outputs can be found in /c/cs223/Hwk9/testFiles.
This file format is hard to read with the naked eye, even after loading into a text
editor. The script /c/cs223/Hwk9/toPng will generate a PNG file that doubles
the pixel size and rescales the 0, 1, 2 pixel values to more reasonable values for
display. This can be called as /c/cs223/Hwk9/toPng filename.pgm to produce
a new file filename.pgm.png. This works best if filename.pgm is already in a
directory you can write to. PNG files can be displayed using most web browsers
and image manipulation tools.
Submit whatever files you need to build maze (including a Makefile that gen-
erates maze when called with no arguments) using /c/cs223/bin/submit 9.
You can apply the public test script in /c/cs223/Hwk9/test.public to your
submitted files using /c/cs223/bin/testit 9 public.
This uses breadth-first search, which makes the search a bit simpler than depth-
first search but requires some more effort to compute the cycle. The program
also includes code for generating random mazes.
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
#include <math.h>
507
#include <limits.h>
struct direction {
signed char x;
signed char y;
};
struct position {
int x;
int y;
};
struct square {
int contents;
struct position parent; /* used by search routine */
};
struct maze {
struct position size; /* rows = size.x, columns = size.y */
struct square *a; /* packed array of squares */
};
508
/* look up a position in a maze */
#define Mref(m, pos) ((m)->a[(pos).y * (m)->size.x + (pos).x])
#define Mget(m, pos) (assert((pos).x >= 0 && (pos).y >= 0 && (pos).x < (m)->size.x && (pos).
return target->x >= 0 && target->y >= 0 && target->x < m->size.x && target->y < m->size.
}
/* free a maze */
void
destroyMaze(struct maze *m)
{
free(m->a);
free(m);
}
m = malloc(sizeof(*m));
assert(m);
return m;
509
}
void
saveMaze(struct maze *m, FILE *f)
{
struct position i;
return count;
}
struct position
randomPosition(const struct maze *m)
{
struct position r;
return r;
}
510
/* generate a random connected maze with no cycles */
struct maze *
generateMaze(struct position size)
{
struct maze *m;
struct position r;
struct position i;
size_t countdown; /* how long to run before we get tired of not making progress */
size_t maxCountdown; /* value to reset countdown to when we make progress */
m = malloc(sizeof(struct maze));
assert(m);
m->size = size;
m->a = malloc(sizeof(struct square) * m->size.x * m->size.y);
assert(m->a);
/* reset countdown */
countdown = maxCountdown;
}
}
return m;
}
511
/* create a cycle by adding one extra PATH square
* that connects two existing squares */
void
mazeAddCycle(struct maze *m)
{
struct position r;
do {
r = randomPosition(m);
} while(Mget(m, r).contents != WALL || countNeighbors(m, r) != 2);
head = tail = 0;
512
}
/* find a root */
/* we don't care what this is, but it can't be a WALL */
do {
root = randomPosition(m);
} while(Mget(m, root).contents != PATH);
/* push root */
Mref(m, root).parent = root;
queue[tail++] = root;
513
} while(!eqPosition(ancestor, root));
doneWithSearch:
free(queue);
}
int
main(int argc, char **argv)
{
struct maze *m;
struct position size = { 80, 60 };
int seed;
switch(argc) {
case 1:
/* sample solution for the assignment */
m = loadMaze(stdin);
mazeSearchForCycle(m);
saveMaze(m, stdout);
destroyMaze(m);
break;
case 4:
/* generate a new test image */
/* usage is ./maze width height seed */
/* if seed is negative, use absolute value and don't put in cycle */
size.x = atoi(argv[1]);
size.y = atoi(argv[2]);
seed = atoi(argv[3]);
514
break;
default:
fprintf(stderr, "Usage %s or %s width height seed\n", argv[0], argv[0]);
return 1;
}
return 0;
}
examples/2015/hw/9/maze.c
And the Makefile.
Hi Jim,
Several of your students for 223 were up late last night in the Zoo
working on their assignments, and they seemed to be getting hung up on
some coding issues. They were pretty frustrated with some standard
language/debugging issues, so I helped them get the type-checker and
Valgrind to stop yelling at them. I noticed some recurring problems and I
thought I'd pass them on to you. They're pretty standard mistakes, and
I've made most of them myself at some point, either in your class or in
Stan's. It occurred to me that there might be more confused people than
were around last night, and they'd probably appreciate it if someone told
them about these sort of things. I'm not trying to intrude on how you
teach the class; I just thought this feedback would be helpful and I
wasn't sure that it would find its way to you otherwise. I'm sure you've
already taught them several of these, and I understand that sometimes
students just don't pay attention. Still, these seem like good points to
hammer down:
515
people didn't seem to realize that a char* is 4 bytes rather than 1.)
3. I think it would be helpful if you explained why, when using
realloc(), it's a good idea to increase the allocated size
multiplicatively rather than additively. Besides, everyone loves the
"tearing down the hotel" metaphor. :)
4. If they use call-by-reference, they had better make sure that they
keep the same reference. So if they pass in a pointer as an argument to a
function, they shouldn't call malloc() or realloc() on that function.
(Mention the double pointer as another option.) Most people will make
this mistake eventually if no one warns them about it. When I was
learning C, I sort of viewed malloc() and realloc() as magical
memory-increasing functions; that is to say, I didn't think very hard
about the meaning of assigning a pointer to malloc()'s return value. I
suspect some of your students would benefit from having the details
spelled out. (Or spelled out again, if you've already done that.)
5. It's possible to get through a lot (but not all) of the CS major
without learning basic Unix shell syntax, but that's really just wasted
time. Pipes, backgrounding, man, scp, and grep really help even at the
intro level. I realize the purpose of the class isn't to teach Unix, but
in past years I think there was a TA help session on these things. They
don't need to know how to write their own Emacs modes, but the basics
would definitely be helpful.
6. malloc/free -- If Valgrind/gdb reports a problem inside of malloc() or
free(), chances are that the student has *not* discovered a bug in gcc.
(I just heard how one of Zhong's students' proved the correctness of the
libraries for his thesis; that's pretty cool.) Explain why you can't
malloc() twice on the same pointer. Explain how with multidimensional
pointers, you must malloc/free each dimension separately. Drill down the
one-to-one correspondence between malloc'ing and free'ing.
7. Null characters: It's not obvious to newbies that some library functions
require them, particularly null-terminated strings. Tell them that
char*'s must be null terminated in order for <string.h>
functions to work.
8. Off-by-one errors: Tell people that when all else fails, take a hard
look at their comparison operators; i. e. make sure that > shouldn't
really be a >=.
9. This is probably another thing for a help session or workshop, but I
feel almost everyone could benefit from basic software engineering
methodology. Stylistic awkwardness I noticed:
--Using a mess of if-then-else's instead of nested control
structures.
--Using while-loops with iterators that get initialized right
before the beginning of the loop and get incremented with each iteration,
when they could be using for-loops.
--Doing the setup work for a loop right before the beginning of
the loop and then at the end of every iteration, instead of at the
516
beginning of every iteration. Conversely: doing the cleanup work at the
beginning of every iteration and then after the loop has completed.
10. Tell them to use assert(). (Frequently.) When you cover binary
search, using placement of debugging statements in code in order to pin
down an error might be an instructive example.
11. Tell them to use either printf statements or a debugger to debug. I
think they can figure out how to do this on their own, they just need to
be told it's a good idea.
Best,
Jim
517