fix text of tutorials
This commit is contained in:
parent
525933d0a3
commit
87c110506d
|
@ -234,7 +234,7 @@ would therefore be subject to garbage collection. A heap box that is
|
|||
unrooted is one such that no pointer values in the heap point to
|
||||
it. It would violate memory safety for the box that was originally
|
||||
assigned to `x` to be garbage-collected, since a non-heap
|
||||
pointer---`y`---still points into it.
|
||||
pointer *`y`* still points into it.
|
||||
|
||||
> ***Note:*** Our current implementation implements the garbage collector
|
||||
> using reference counting and cycle detection.
|
||||
|
@ -475,7 +475,7 @@ but otherwise it requires that the data reside in immutable memory.
|
|||
|
||||
# Returning borrowed pointers
|
||||
|
||||
So far, all of the examples we've looked at use borrowed pointers in a
|
||||
So far, all of the examples we have looked at, use borrowed pointers in a
|
||||
“downward” direction. That is, a method or code block creates a
|
||||
borrowed pointer, then uses it within the same scope. It is also
|
||||
possible to return borrowed pointers as the result of a function, but
|
||||
|
@ -509,7 +509,7 @@ guaranteed to refer to a distinct lifetime from the lifetimes of all
|
|||
other parameters.
|
||||
|
||||
Named lifetimes that appear in function signatures are conceptually
|
||||
the same as the other lifetimes we've seen before, but they are a bit
|
||||
the same as the other lifetimes we have seen before, but they are a bit
|
||||
abstract: they don’t refer to a specific expression within `get_x()`,
|
||||
but rather to some expression within the *caller of `get_x()`*. The
|
||||
lifetime `r` is actually a kind of *lifetime parameter*: it is defined
|
||||
|
|
|
@ -481,7 +481,7 @@ an `Error` result.
|
|||
TODO: Need discussion of `future_result` in order to make failure
|
||||
modes useful.
|
||||
|
||||
But not all failure is created equal. In some cases you might need to
|
||||
But not all failures are created equal. In some cases you might need to
|
||||
abort the entire program (perhaps you're writing an assert which, if
|
||||
it trips, indicates an unrecoverable logic error); in other cases you
|
||||
might want to contain the failure at a certain boundary (perhaps a
|
||||
|
|
|
@ -1084,8 +1084,8 @@ let managed_box : @Point = @Point { x: 5.0, y: 1.0 };
|
|||
let owned_box : ~Point = ~Point { x: 7.0, y: 9.0 };
|
||||
~~~
|
||||
|
||||
Suppose we wanted to write a procedure that computed the distance
|
||||
between any two points, no matter where they were stored. For example,
|
||||
Suppose we want to write a procedure that computes the distance
|
||||
between any two points, no matter where they are stored. For example,
|
||||
we might like to compute the distance between `on_the_stack` and
|
||||
`managed_box`, or between `managed_box` and `owned_box`. One option is
|
||||
to define a function that takes two arguments of type point—that is,
|
||||
|
@ -1230,7 +1230,7 @@ let area = rect.area();
|
|||
~~~
|
||||
|
||||
You can write an expression that dereferences any number of pointers
|
||||
automatically. For example, if you felt inclined, you could write
|
||||
automatically. For example, if you feel inclined, you could write
|
||||
something silly like
|
||||
|
||||
~~~
|
||||
|
@ -1808,7 +1808,7 @@ s.draw_borrowed();
|
|||
~~~
|
||||
|
||||
Implementations may also define standalone (sometimes called "static")
|
||||
methods. The absence of a `self` paramater distinguishes such methods.
|
||||
methods. The absence of a `self` parameter distinguishes such methods.
|
||||
These methods are the preferred way to define constructor functions.
|
||||
|
||||
~~~~ {.xfail-test}
|
||||
|
@ -2522,7 +2522,7 @@ will not be compiled successfully.
|
|||
|
||||
## A minimal example
|
||||
|
||||
Now for something that you can actually compile yourself. We have
|
||||
Now for something that you can actually compile yourself, we have
|
||||
these two files:
|
||||
|
||||
~~~~
|
||||
|
|
Loading…
Reference in New Issue