Up: Program Design

Aliasing

slide 01 Welcome to the third episode of the Software Carpentry lecture on program design using invasion percolation as an example. In this episode we’ll look at aliasing, and some bugs that can arise when your programs depend on it.
slide 02 As you recall, we’re implementing a 2D grid using a list of lists.
slide 03 A single list serves as the “spine” of the structure…
slide 04 …and then each of the sublists stores actual values.
slide 05 Here’s some code that creates an N×N grid containing 1′s.
slide 06 Here’s some other code that is almost identical, but has a bug.
slide 07 The only change we’ve made is to introduce a variable called EMPTY so that we can say “grid dot append EMPTY” inside our outermost loop.
slide 08 How can this be a bug? Aren’t meaningful variable names supposed to be a good thing?
slide 09 Well, let’s trace the execution of this program. We start by assigning an empty list to the variable grid.
slide 10 We then assign another empty list to the variable EMPTY.
slide 11 In the first pass through our loop, we append the empty list pointed to by EMPTY to the list pointed to by grid to get the structure shown on the left.
slide 12 We then go into our inner loop and append a 1 to that sublist.
slide 13 Going around the inner loop again, we append another 1…
slide 14 …and another.
slide 15 We then go back to the outer loop and append EMPTY again. The structure shown on the left is now broken: both cells of the list pointed to by grid point to the same sublist, because EMPTY is still pointing to that list, even though we’ve changed it.
slide 16 So now, when we go into the inner loop, we’re appending 1′s to the same list that we were using last time.
slide 17 You see the problem…
slide 18 Any time we use indirection, it allows aliasing, i.e., it allows us to have two or more references to the same object.
slide 19 This can be very useful…
slide 20 …in fact, in some situations it’s absolutely essential…
slide 21 …but it can also be a rich source of bugs.
slide 22 Whenever you’re in doubt about what your data structures are supposed to look like, draw a picture and check it against the code.
slide 23 There are some tools that can do this for you automatically…
slide 24 …but so far, none of them has been widely adopted.
slide 25

  1. No comments yet.
  1. No trackbacks yet.