From 54169ef43f57847913ebec7e021c1267663a5d12 Mon Sep 17 00:00:00 2001 From: Pawel Duzinkiewicz Date: Fri, 24 Nov 2017 20:43:10 +0100 Subject: [PATCH] listing/figure numbering in chapter 15 corrected --- second-edition/src/ch15-03-drop.md | 12 +++---- second-edition/src/ch15-04-rc.md | 18 +++++------ .../src/ch15-05-interior-mutability.md | 22 ++++++------- .../src/ch15-06-reference-cycles.md | 32 +++++++++---------- 4 files changed, 42 insertions(+), 42 deletions(-) diff --git a/second-edition/src/ch15-03-drop.md b/second-edition/src/ch15-03-drop.md index 6626e20ff..d06602fa5 100644 --- a/second-edition/src/ch15-03-drop.md +++ b/second-edition/src/ch15-03-drop.md @@ -35,7 +35,7 @@ for clean up? --> this code gets run. It's hard to experience the cleaning up unless we print something. /Carol --> -Listing 15-8 shows a `CustomSmartPointer` struct whose only custom +Listing 15-16 shows a `CustomSmartPointer` struct whose only custom functionality is that it will print out `Dropping CustomSmartPointer!` when the instance goes out of scope. This will demonstrate when Rust runs the `drop` function: @@ -69,7 +69,7 @@ fn main() { } ``` -Listing 15-8: A `CustomSmartPointer` struct that +Listing 15-16: A `CustomSmartPointer` struct that implements the `Drop` trait, where we would put our clean up code. The `Drop` trait is included in the prelude, so we don’t need to import it. We @@ -122,7 +122,7 @@ up a value early. One example is when using smart pointers that manage locks; you may want to force the `drop` method that releases the lock to run so that other code in the same scope can acquire the lock. First, let’s see what happens if we try to call the `Drop` trait’s `drop` method ourselves by -modifying the `main` function from Listing 15-8 as shown in Listing 15-9: +modifying the `main` function from Listing 15-16 as shown in Listing 15-17: -In Listing 15-14, we’ll change `main` so that it has an inner scope around list +In Listing 15-22, we’ll change `main` so that it has an inner scope around list `c`, so that we can see how the reference count changes when `c` goes out of scope. At each point in the program where the reference count changes, we’ll print out the reference count, which we can get by calling the @@ -202,7 +202,7 @@ fn main() { } ``` -Listing 15-14: Printing out the reference count +Listing 15-22: Printing out the reference count This will print out: diff --git a/second-edition/src/ch15-05-interior-mutability.md b/second-edition/src/ch15-05-interior-mutability.md index ac32be18a..053dc2ec0 100644 --- a/second-edition/src/ch15-05-interior-mutability.md +++ b/second-edition/src/ch15-05-interior-mutability.md @@ -156,7 +156,7 @@ mechanism for sending the messages: the application could choose to put a message in the application, send an email, send a text message, or something else. Our library doesn’t need to know about that detail; all it needs is something that implements a trait we’ll provide called `Messenger`. Listing -15-15 shows our library code: +15-23 shows our library code: Filename: src/lib.rs @@ -197,7 +197,7 @@ impl<'a, T> LimitTracker<'a, T> } ``` -Listing 15-15: A library to keep track of how close to a +Listing 15-23: A library to keep track of how close to a maximum value a value is, and warn when the value is at certain levels One important part of this code is that the `Messenger` trait has one method, @@ -216,7 +216,7 @@ text message when we call `send`, will only keep track of the messages it’s told to send. We can create a new instance of the mock object, create a `LimitTracker` that uses the mock object, call the `set_value` method on `LimitTracker`, then check that the mock object has the messages we expect. -Listing 15-16 shows an attempt of implementing a mock object to do just that, +Listing 15-24 shows an attempt of implementing a mock object to do just that, but that the borrow checker won’t allow: Filename: src/lib.rs @@ -254,7 +254,7 @@ mod tests { } ``` -Listing 15-16: An attempt to implement a `MockMessenger` +Listing 15-24: An attempt to implement a `MockMessenger` that isn’t allowed by the borrow checker This test code defines a `MockMessenger` struct that has a `sent_messages` @@ -295,7 +295,7 @@ definition (feel free to try and see what error message you get). This is where interior mutability can help! We’re going to store the `sent_messages` within a `RefCell`, and then the `send` message will be able to -modify `sent_messages` to store the messages we’ve seen. Listing 15-17 shows +modify `sent_messages` to store the messages we’ve seen. Listing 15-25 shows what that looks like: Filename: src/lib.rs @@ -334,7 +334,7 @@ mod tests { } ``` -Listing 15-17: Using `RefCell` to be able to mutate an +Listing 15-25: Using `RefCell` to be able to mutate an inner value while the outer value is considered immutable The `sent_messages` field is now of type `RefCell>` instead of @@ -376,8 +376,8 @@ mutable borrow at any point in time. If we try to violate these rules, rather than getting a compiler error like we would with references, the implementation of `RefCell` will `panic!` at -runtime. Listing 15-18 shows a modification to the implementation of `send` -from Listing 15-17 where we’re deliberately trying to create two mutable +runtime. Listing 15-26 shows a modification to the implementation of `send` +from Listing 15-25 where we’re deliberately trying to create two mutable borrows active for the same scope in order to illustrate that `RefCell` prevents us from doing this at runtime: @@ -395,7 +395,7 @@ impl Messenger for MockMessenger { } ``` -Listing 15-18: Creating two mutable references in the +Listing 15-26: Creating two mutable references in the same scope to see that `RefCell` will panic We create a variable `one_borrow` for the `RefMut` smart pointer returned from @@ -439,7 +439,7 @@ For example, recall the cons list example from Listing 15-13 where we used `Rc` to let us have multiple lists share ownership of another list. Because `Rc` only holds immutable values, we aren’t able to change any of the values in the list once we’ve created them. Let’s add in `RefCell` to get the -ability to change the values in the lists. Listing 15-19 shows that by using a +ability to change the values in the lists. Listing 15-27 shows that by using a `RefCell` in the `Cons` definition, we’re allowed to modify the value stored in all the lists: @@ -472,7 +472,7 @@ fn main() { } ``` -Listing 15-19: Using `Rc>` to create a +Listing 15-27: Using `Rc>` to create a `List` that we can mutate We create a value that’s an instance of `Rc` and store it in a diff --git a/second-edition/src/ch15-06-reference-cycles.md b/second-edition/src/ch15-06-reference-cycles.md index de183aef0..fc5b4f536 100644 --- a/second-edition/src/ch15-06-reference-cycles.md +++ b/second-edition/src/ch15-06-reference-cycles.md @@ -13,7 +13,7 @@ never reach 0, and the values will never be dropped. Let’s take a look at how a reference cycle might happen and how to prevent it, starting with the definition of the `List` enum and a `tail` method in Listing -15-20: +15-28: Filename: src/main.rs @@ -38,7 +38,7 @@ impl List { } ``` -Listing 15-20: A cons list definition that holds a +Listing 15-28: A cons list definition that holds a `RefCell` so that we can modify what a `Cons` variant is referring to We’re using another variation of the `List` definition from Listing 15-6. The @@ -58,8 +58,8 @@ uses the definitions. We just broke these apart to avoid having a lot of code and then a lot of explanation, I'd be fine having this be one big listing if you think that would be better /Carol --> -In listing 15-21, we’re adding a `main` function that uses the definitions from -Listing 15-20. This code creates a list in `a`, a list in `b` that points to +In listing 15-29, we’re adding a `main` function that uses the definitions from +Listing 15-28. This code creates a list in `a`, a list in `b` that points to the list in `a`, and then modifies the list in `a` to point to `b`, which creates a reference cycle. There are `println!` statements along the way to show what the reference counts are at various points in this process. @@ -114,7 +114,7 @@ fn main() { } ``` -Listing 15-21: Creating a reference cycle of two `List` +Listing 15-29: Creating a reference cycle of two `List` values pointing to each other We create an `Rc` instance holding a `List` value in the variable `a` with an @@ -160,11 +160,11 @@ However, because `a` is still referencing the `Rc` that was in `b`, that `Rc` has a count of 1 rather than 0, so the memory the `Rc` has on the heap won’t be dropped. The memory will just sit there with a count of one, forever. -To visualize this, we’ve created a reference cycle that looks like Figure 15-22: +To visualize this, we’ve created a reference cycle that looks like Figure 15-30: Reference cycle of lists -Figure 15-22: A reference cycle of lists `a` and `b` +Figure 15-30: A reference cycle of lists `a` and `b` pointing to each other If you uncomment the last `println!` and run the program, Rust will try and @@ -208,7 +208,7 @@ Another solution is reorganizing your data structures so that some references express ownership and some references don’t. In this way, we can have cycles made up of some ownership relationships and some non-ownership relationships, and only the ownership relationships affect whether a value may be dropped or -not. In Listing 15-20, we always want `Cons` variants to own their list, so +not. In Listing 15-28, we always want `Cons` variants to own their list, so reorganizing the data structure isn’t possible. Let’s look at an example using graphs made up of parent nodes and child nodes to see when non-ownership relationships are an appropriate way to prevent reference cycles. @@ -284,7 +284,7 @@ a `RefCell` in `children` around the `Vec`. Next, let’s use our struct definition and create one `Node` instance named `leaf` with the value 3 and no children, and another instance named `branch` -with the value 5 and `leaf` as one of its children, as shown in Listing 15-23: +with the value 5 and `leaf` as one of its children, as shown in Listing 15-31: Filename: src/main.rs @@ -311,7 +311,7 @@ fn main() { } ``` -Listing 15-23: Creating a `leaf` node with no children +Listing 15-31: Creating a `leaf` node with no children and a `branch` node with `leaf` as one of its children We clone the `Rc` in `leaf` and store that in `branch`, meaning the `Node` in @@ -365,7 +365,7 @@ you think? It seems repetitive to explain this every time. /Carol --> This way, a node will be able to refer to its parent node, but does not own its -parent. In Listing 15-24, let’s update `main` to use this new definition so +parent. In Listing 15-32, let’s update `main` to use this new definition so that the `leaf` node will have a way to refer to its parent, `branch`: Creating the `leaf` node looks similar to how creating the `leaf` node looked -in Listing 15-23, with the exception of the `parent` field: `leaf` starts out +in Listing 15-31, with the exception of the `parent` field: `leaf` starts out without a parent, so we create a new, empty `Weak` reference instance. At this point, when we try to get a reference to the parent of `leaf` by using @@ -444,7 +444,7 @@ parent? --> When we print out the parent of `leaf` again, this time we’ll get a `Some` variant holding `branch`: `leaf` can now access its parent! When we print out `leaf`, we also avoid the cycle that eventually ended in a stack overflow like -we had in Listing 15-21: the `Weak` references are printed as `(Weak)`: +we had in Listing 15-29: the `Weak` references are printed as `(Weak)`: ```text leaf parent = Some(Node { value: 5, parent: RefCell { value: (Weak) }, @@ -462,7 +462,7 @@ Let’s look at how the `strong_count` and `weak_count` values of the `Rc` instances change by creating a new inner scope and moving the creation of `branch` into that scope. This will let us see what happens when `branch` is created and then dropped when it goes out of scope. The modifications are shown -in Listing 15-25: +in Listing 15-33: Filename: src/main.rs @@ -510,7 +510,7 @@ fn main() { } ``` -Listing 15-25: Creating `branch` in an inner scope and +Listing 15-33: Creating `branch` in an inner scope and examining strong and weak reference counts Once `leaf` is created, its `Rc` has a strong count of 1 and a weak count of 0.