|
| 1 | +# Layout |
| 2 | + |
| 3 | +Let us begin by first studying the structure of our enemy. A Doubly-Linked List is conceptually simple, but that's how it decieves and manipulates you. It's the same kind of linked list we've looked at over and over, but the links go both ways. Double the links, double the evil. |
| 4 | + |
| 5 | +So rather than this (gonna drop the Some/None stuff to keep it cleaner): |
| 6 | + |
| 7 | +```text |
| 8 | +... -> (A, ptr) -> (B, ptr) -> ... |
| 9 | +``` |
| 10 | + |
| 11 | +We have this: |
| 12 | + |
| 13 | +```text |
| 14 | +... <-> (ptr, A, ptr) <-> (ptr, B, ptr) <-> ... |
| 15 | +``` |
| 16 | + |
| 17 | +This lets you traverse the list from either direction, or seek back and forth with a [cursor](https://doc.rust-lang.org/std/collections/struct.LinkedList.html#method.cursor_back_mut). |
| 18 | + |
| 19 | +In exchange for this flexibility, every node has to store twice as many pointers, and every operations has to fix up way more pointers. It's a significant enough complication that it's a lot easier to make a mistake, so we're going to be doing a lot of testing. |
| 20 | + |
| 21 | +You might have also noticed that I intentionally haven't drawn the *ends* of the list. This is because this one of the places where there are genuinely defensible options for our implementation. We *definitely* need our implementation to have two pointers: one to the start of the list, and one to the end of the list. |
| 22 | + |
| 23 | +There are two notable ways to do this in my mind: "traditional" and "dummy node". |
| 24 | + |
| 25 | +The traditional approach is the simple extension of how we did a Stack — just store the head and tail pointers on the stack: |
| 26 | + |
| 27 | +```text |
| 28 | +[ptr, ptr] <-> (ptr, A, ptr) <-> (ptr, B, ptr) |
| 29 | + ^ ^ |
| 30 | + +----------------------------------------+ |
| 31 | +``` |
| 32 | + |
| 33 | +This is fine, but it has one downside: corner cases. There are now two edges to our list, which means twice as many corner cases. It's easy to forget one and have a serious bug. |
| 34 | + |
| 35 | +The dummy node approach attempts to smooth out these corner cases by adding an extra node to our list which contains no data but links the two ends together into a ring: |
| 36 | + |
| 37 | +```text |
| 38 | +[ptr] -> (ptr, ?DUMMY?, ptr) <-> (ptr, A, ptr) <-> (ptr, B, ptr) |
| 39 | + ^ ^ |
| 40 | + +-------------------------------------------------+ |
| 41 | +``` |
| 42 | + |
| 43 | +By doing this, every node *always* has actual pointers to a previous and next node in the list. Even when you remove the last element from the list, you just end up stitching the dummy node to point at itself: |
| 44 | + |
| 45 | +```text |
| 46 | +[ptr] -> (ptr, ?DUMMY?, ptr) |
| 47 | + ^ ^ |
| 48 | + +-------------+ |
| 49 | +``` |
| 50 | + |
| 51 | +There is a part of me that finds this *very* satisfying and elegant. Unfortunately, it has a couple practical problems: |
| 52 | + |
| 53 | +Problem 1: An extra indirection and allocation, especially for the empty list, which must include the dummy node. Potential solutions include: |
| 54 | + |
| 55 | +* Don't allocate the dummy node until something is inserted: simple and effective, but it adds back some of the corner cases we were trying to avoid by using dummy pointers! |
| 56 | + |
| 57 | +* Use a static copy-on-write empty singleton dummy node, with some really clever scheme that lets the Copy-On-Write checks piggy-back on normal checks: look I'm really tempted, I really do love that shit, but we can't go down that dark path in this book. Read [ThinVec's sourcecode](https://docs.rs/thin-vec/0.2.4/src/thin_vec/lib.rs.html#319-325) if you want to see that kind of perverted stuff. |
| 58 | + |
| 59 | +* Store the dummy node on the stack - not practical in a language without C++-style move-constructors. I'm sure there's something weird thing we could do here with [pinning](https://doc.rust-lang.org/std/pin/index.html) but we're not gonna. |
| 60 | + |
| 61 | +Problem 2: What *value* is stored in the dummy node? Sure if it's an integer it's fine, but what if we're storing a list full of `Box`? It may be impossible for us to initialized this value! Potential solutions include: |
| 62 | + |
| 63 | +* Make every node store `Option<T>`: simple and effective, but also bloated and annoying. |
| 64 | + |
| 65 | +* Make every node store [`MaybeUninit<T>`](https://doc.rust-lang.org/std/mem/union.MaybeUninit.html). Horrifying and annoying. |
| 66 | + |
| 67 | +* *Really* careful and clever inheritance-style type punning so the dummy node doesn't include the data field. This is also tempting but it's extremely dangerous and annoying. Read [BTreeMap's sourcecode](https://doc.rust-lang.org/1.55.0/src/alloc/collections/btree/node.rs.html#49-104) if you want to see that kind of perverted stuff. |
| 68 | + |
| 69 | +The problems really outweight the convenience for a language like Rust, so we're going to stick to the traditional layout. We'll be using the same basic design as we did for the unsafe queue in the previous chapter: |
| 70 | + |
| 71 | +```rust |
| 72 | +pub type Link<T> = *mut Node<T>; |
| 73 | + |
| 74 | +pub struct List<T> { |
| 75 | + front: Link<T>, |
| 76 | + back: Link<T>, |
| 77 | +} |
| 78 | + |
| 79 | +pub struct Node<T> { |
| 80 | + prev: Link<T>, |
| 81 | + next: Link<T>, |
| 82 | + elem: T, |
| 83 | +} |
| 84 | +``` |
| 85 | + |
| 86 | +This isn't quite a *true* production-quality layout yet. It's *fine* but there's magic tricks we can do to tell Rust what we're doing a bit better. Something we'll look at later. Maybe. |
0 commit comments