5.8 Ownership
This section is one of the three parts of rust that describes the ownership system. Ownership is the most unique and compelling feature of Rust, a feature that rust programmers must be familiar with. Ownership allows Rust to achieve its greatest design goal, memory security. Here are some different concepts, each with its own chapters:
- Ownership that you're reading
- Borrowing (borrowing, 5.9), and its associated attribute ' references '
- Lifetime (5.10), and advanced features of borrowing
These three are relevant and gradual. You have to fully understand this three-part.
5.8.1 USD
Before we discuss the details, there are two important notes about the ownership system.
Rust is committed to security and fast. It achieves this by "0 spent abstraction (zero-cost abstractions)", which means that abstraction costs the least in rust. All the analysis we discussed in this chapter is done at compile time. You don't have to worry about running-time overhead. .
However, the system still has some overhead: the learning curve. Many of Rust's beginners will experience us as a "fight against borrowing and testing." Process. That is, the rust compiler refuses to compile code that programmers think is available. Because the programmer's idea of ownership is often in conflict with the real rust rules. You will try to do something similar at the beginning. But that's good news, More experienced rust programmers feedback that once they have adapted to this rule for a period of time, they will struggle less and fewer.
With this cushion, we will learn the ownership system.
5.8.2 Ownership
Variable bindings have a property in rust: They have ownership of the objects they bind to. That is, when a binding leaves its scope, the resources they bind are freed. For example:
fn Foo () {Let V = vec![ 1, 2, 3];}
When v enters the scope, a new Vec<t> object is created. In this example, the vector allocates memory to three elements on the heap at the same time. When V leaves the Foo () function, it leaves its scope, and rust cleans up all the data associated with the vector. Even the space on the heap. This is sure to happen at the end of the scope.
5.8.3 Move semantics
However, there is a subtle thing: rust guarantees that any resource has only one explicit binding object. For example, if you have a vector, we can assign another binding to it:
Let V = vec! [1, 2, 3];let v2 = v;
However, if you use V in the back, we get an error:
Let V = vec! [1, 2, 3];let v2 = v;println! ("V[0] is: {}", v[0]);
He seems to show this:
A similar situation occurs when you define a function that takes ownership and then passes the bound object as a parameter to the function, and then uses it: FN Take (v:vec<i32>) {
What happens here isn?t important.
}
Let V = vec! [1, 2, 3];
Take (v);
println! ("V[0] is: {}", v[0]);
The same "use of moved value" error occurred. When we passed the ownership, we said we had moved the object we pointed to. You do not have to declare anything at this point, and the rust code will do so by default.
Details:
The reason we can't use it after moving ownership is subtle, but it's important. When we write code like this:
Let V = vec! [1, 2, 3];let v2 = v;
The first line allocates a vector of memory space, V, and all of its data. The vector object is stored on the stack, and it has a pointer to the content on the heap. When we assign V to v2, he creates a copy of the pointer, To V2. This means that at this point there are 2 pointers pointing to the address of the vector on the heap. This can lead to rust security issues and data contention. Therefore, rust prohibits the use of V that has not been moved.
Equally important, optimization removes that copy on the stack, depending on the context. So it's not as inefficient as it seems.
Copy type
We have explained that ownership can no longer use the original bindings after being transferred to another binding. However, there is a feature (trait) that alters this behavior, that is, the copy. We haven't talked about features yet, and you can think of them as a specific type of callout that provides extra behavior. For example:
Let V = 1;let v2 = v;println! ("V is: {}", V);
In this example, V is a i32, which implements the copy feature. That is, just like the move, when we assign V to v2, the copy of the data is generated. However, unlike moving, we can still use v. that is because I32 has no pointers to other data, and one copy of it is a full copy.
We'll discuss the copy later.
5.8.4 MORE:
Of course, if we have to return ownership at the time of using the function:
fn Foo (v:vec<i32>)-vec<i32> {//do stuff with V//hand back Ownership V} This looks ridiculous. When we use more proprietary The time will be worse:
fn foo (v1:vec<i32>, v2:vec<i32>)--(VEC<I32>, Vec<i32>, i32) {
Do stuff with V1 and v2
Hand back ownership, and the result of our function
(v1, v2, 42)
}
Let V1 = vec! [1, 2, 3];
Let V2 = vec! [1, 2, 3];
Let (v1, v2, answer) = foo (v1, v2);
Returns a type, returns a row, and a function call is something that gets complicated. Fortunately, Rust provides a feature that can be borrowed to help us solve this problem. That's the subject of the next section!
Rust Chinese Translation 27
