diff --git a/doc/guide-pointers.md b/doc/guide-pointers.md index 49e5b3c9994..57a0b773d43 100644 --- a/doc/guide-pointers.md +++ b/doc/guide-pointers.md @@ -21,7 +21,7 @@ fn succ(x: &int) -> int { *x + 1 } So I wrote this code to try it out: -~~~rust {.xfail-test} +~~~rust{.xfail-test} fn main() { let number = 5; let succ_number = succ(number); @@ -73,7 +73,7 @@ However. Here are the use-cases for pointers. I've prefixed them with the name of the pointer that satisfies that use-case: -1. Owned: ~Trait must be a pointer, becuase you don't know the size of the +1. Owned: ~Trait must be a pointer, because you don't know the size of the object, so indirection is mandatory. 2. Owned: You need a recursive data structure. These can be infinite sized, so indirection is mandatory. @@ -85,18 +85,18 @@ common, such as C++, please read "A note..." below. or impossible. This is only often useful when a program is very large or very complicated. Using a managed pointer will activate Rust's garbage collection mechanism. -5: Reference: You're writing a function, and you need a pointer, but you don't +5. Reference: You're writing a function, and you need a pointer, but you don't care about its ownership. If you make the argument a reference, callers can send in whatever kind they want. -Five exceptions. That's it. Otherwise, you shouldn't need them. Be skeptical +Five exceptions. That's it. Otherwise, you shouldn't need them. Be sceptical of pointers in Rust: use them for a deliberate purpose, not just to make the compiler happy. ## A note for those proficient in pointers If you're coming to Rust from a language like C or C++, you may be used to -passing things by reference, or passing things by pointer. In some langauges, +passing things by reference, or passing things by pointer. In some languages, like Java, you can't even have objects without a pointer to them. Therefore, if you were writing this Rust code: @@ -150,7 +150,7 @@ fn main() { } ~~~ -But won't this be inefficent? Well, that's a complicated question, but it's +But won't this be inefficient? Well, that's a complicated question, but it's important to know that Rust, like C and C++, store aggregate data types 'unboxed,' whereas languages like Java and Ruby store these types as 'boxed.' For smaller structs, this way will be more efficient. For larger ones, it may @@ -173,7 +173,7 @@ These two properties make for three use cases. ## References to Traits -Traits must be referenced through a pointer, becuase the struct that implements +Traits must be referenced through a pointer, because the struct that implements the trait may be a different size than a different struct that implements the trait. Therefore, unboxed traits don't make any sense, and aren't allowed. @@ -199,7 +199,7 @@ This prints: Cons(1, ~Cons(2, ~Cons(3, ~Nil))) ~~~ -The inner lists _must_ be an owned pointer, becuase we can't know how many +The inner lists _must_ be an owned pointer, because we can't know how many elements are in the list. Without knowing the length, we don't know the size, and therefore require the indirection that pointers offer. @@ -261,7 +261,7 @@ program is very large and complicated. For example, let's say you're using an owned pointer, and you want to do this: -~~~rust {.xfail-test} +~~~rust{.xfail-test} struct Point { x: int, y: int, @@ -315,7 +315,7 @@ managed pointers: 1. They activate Rust's garbage collector. Other pointer types don't share this drawback. 2. You cannot pass this data to another task. Shared ownership across -concurrency boundaries is the source of endless pain in other langauges, so +concurrency boundaries is the source of endless pain in other languages, so Rust does not let you do this. # References @@ -355,7 +355,7 @@ takes in two references, but we give it a managed and unique pointer. Of course, if this were a real program, we wouldn't have any of these pointers, they're just there to demonstrate the concepts. -So how is this hard? Well, because we're igorning ownership, the compiler needs +So how is this hard? Well, because we're ignoring ownership, the compiler needs to take great care to make sure that everything is safe. Despite their complete safety, a reference's representation at runtime is the same as that of an ordinary pointer in a C program. They introduce zero overhead. The compiler @@ -365,14 +365,14 @@ This theory is called 'region pointers,' and involve a concept called 'lifetimes'. Here's the simple explanation: would you expect this code to compile? -~~~rust {.xfail-test} +~~~rust{.xfail-test} fn main() { println(x.to_str()); let x = 5; } ~~~ -Probably not. That's becuase you know that the name `x` is valid from where +Probably not. That's because you know that the name `x` is valid from where it's declared to when it goes out of scope. In this case, that's the end of the `main` function. So you know this code will cause an error. We call this duration a 'lifetime'. Let's try a more complex example: @@ -394,7 +394,7 @@ Here, we're borrowing a pointer to `x` inside of the `if`. The compiler, however is able to determine that that pointer will go out of scope without `x` being mutated, and therefore, lets us pass. This wouldn't work: -~~~rust {.xfail-test} +~~~rust{.xfail-test} fn main() { let mut x = ~5; if *x < 10 { @@ -427,7 +427,7 @@ great detail, so if you want the full details, check that out. # Returning Pointers -We've talked a lot about funtions that accept various kinds of pointers, but +We've talked a lot about functions that accept various kinds of pointers, but what about returning them? Here's the rule of thumb: only return a unique or managed pointer if you were given one in the first place.