Make some further edits to the changes in #1886

This commit is contained in:
Carol (Nichols || Goulding) 2020-12-09 21:30:13 -05:00
parent ea49874970
commit d28183f901
No known key found for this signature in database
GPG Key ID: D04B39A6CA243902
1 changed files with 10 additions and 9 deletions

View File

@ -64,15 +64,16 @@ moment, well get this output:
{{#include ../listings/ch15-smart-pointers/listing-15-26/output.txt}}
```
The reference count of the `Rc<List>` instances in both `a` and `b` are 2
after we change the list in `a` to point to `b`. At the end of `main`, Rust
drops `b` which decreases the reference count of the `b` `Rc<List>` instance
by 1. However, the `b` `Rc<List>` can not be collected, because its reference
count is 1, not 0. Then Rust drops `a` which decreases the reference count of
the `a` `Rc<List>` instance by 1. This instance can not be collected either,
because its count is 1, since the uncollected `b` `Rc<List>` instance still
refers to it. The memory allocated to the list will remain uncollected forever.
To visualize this reference cycle, weve created a diagram in Figure 15-4.
The reference count of the `Rc<List>` instances in both `a` and `b` are 2 after
we change the list in `a` to point to `b`. At the end of `main`, Rust drops the
variable `b`, which decreases the reference count of the `Rc<List>` instance
from 2 to 1. The memory that `Rc<List>` has on the heap wont be dropped at
this point, because its reference count is 1, not 0. Then Rust drops `a`, which
decreases the reference count of the `a` `Rc<List>` instance from 2 to 1 as
well. This instance's memory cant be dropped either, because the other
`Rc<List>` instance still refers to it. The memory allocated to the list will
remain uncollected forever. To visualize this reference cycle, weve created a
diagram in Figure 15-4.
<img alt="Reference cycle of lists" src="img/trpl15-04.svg" class="center" />