7.11.1. Ownership rule #

There are three rules for ownership:

• Each value in Rust has a variable called its owner.

• There can be only one owner at a time.

• This value is deleted when the owner is not in the scope of the program.

These three rules are the basis of the concept of ownership.

Next, we will introduce concepts related to the concept of ownership.

7.11.2. Variable range #

We use the following program to describe the concept of variable scope:

{
//Invalid variable s before declaration
Lets="runoob";
//Here is the available range of variable s
}
//Variable range has ended, variable s is invalid

A variable scope is an attribute of a variable that represents the feasible domain of the variable and is valid by default from declaring the variable to the end of the variable’s domain.

7.11.3. Memory and allocation #

If we define a variable and assign it a value, the value of that variable exists in memory. This situation is very common. But if the length of the data we need to store is uncertain (such as a string entered by the user), we cannot specify the length of the data at the time of definition, and we will not be able to make the program allocate a fixed length of memory space for data storage during the compilation phase. Some people say that allocating as much space as possible can solve the problem, but this method is very uncivilized. This needs to provide a mechanism for the program to apply for memory while the program is running-heap. All the “memory resources” in this chapter refer to the memory space occupied by the heap.

Where there is allocation, there is release, and programs cannot occupy a certain memory resource all the time. Therefore, the key factor to determine whether resources are wasted is whether resources are released in a timely manner.

Let’s write the sample string program in C language equivalent:

{
    char *s = strdup("runoob");
    free(s); // Release s resources
}

Obviously, there is no call in Rust free function to release the resources of the string s (I know this is not the correct way to write in C because “runoob” is not in the heap, so let’s assume it is). The reason why Rust does not explicitly release the step is that when the variable range ends, the Rust compiler automatically adds the step of calling the release resource function.

This mechanism seems simple: it just helps programmers add a function call that frees resources in the right place. But this simple mechanism can effectively solve one of the most troublesome programming problems in history.

7.11.4. The way variables interact with data #

There are two main ways for variables to interact with data: Move and Clone:

7.11.5. move #

Multiple variables can interact with the same data in different ways in Rust:

let x = 5;
let y = x;

This program binds the value 5 to the variable x, then copies the value of xand assigns it to the variable y. There will now be two values of 5 in the stack. The data in this case is of the “basic data” type and does not needto be stored in the heap, and the “move” mode of the data in the stack iscopied directly, which does not take longer or more storage space. The basic data types are as follows:

• All integer types, such as i32 、 u32 、 i64 , etc.

• Boolean type bool with a value of true or false .

• All floating point types f32 and f64 .

• Character type char .

• A tuple that contains only the above types of data.

But if the interactive data is in the heap, it is a different situation:

let s1 = String::from("hello");
let s2 = s1;

The first step is to produce a String object with a value of “hello”.Where “hello” can be thought of as data of uncertain length, which needs to be stored in the heap.

The situation in the second step is slightly different (this is not entirelytrue, it is only for comparative reference):

As shown in the figure: two String object in the stack, each String objects have a pointer to the “hello” string in the heap. In giving s2 when assigning, only the data in the stack is copied, and thestring in the heap is still the original string.

As we said earlier, when a variable is out of range, Rust automatically calls the free resource function and cleans up the variable’s heap memory. But s1 and s2 if both are released, the “hello” in the heap areais released twice, which is not allowed by the system. In order to ensure safety, give s2 when assigning values s1 is no longer effective.That’s right. I’m putting s1 value assigned to the s2 later, s1 will no longer be available for use. The following procedure is wrong:

let s1 = String::from("hello");
let s2 = s1;
println!("{}, world!", s1); // Error! S1 has expired

So the actual situation is:

S1 exists in name only.

7.11.6. Clone #

Rust reduces the cost of running the program as much as possible, so by default, longer data is stored in the heap and the data is exchanged in a mobile manner. But if you need to simply make a copy of the data for other use, you can use the second way to interact with the data-cloning.

fn main() {
    let s1 = String::from("hello");
    let s2 = s1.clone();
    println!("s1 = {}, s2 = {}", s1, s2);
}

s1 = hello, s2 = hello

7.11.7. Ownership mechanism involving functions #

This is the most complicated case for variables.

How do you safely handle ownership if you pass a variable to another function as an argument to the function?

The following program describes how the ownership mechanism works in this case:

Fn main(){
Lets=String:: from ("hello");
//S declared valid
Take_ Ownership (s);
//The value of s is passed into the function as a parameter
//So it can be considered that s has been moved and is no longer valid from here on
Let x=5;
//X declared valid
Make_ Copy (x);
//The value of x is passed into the function as a parameter
//But x is the basic type and still valid
//You can still use x here, but not s
}//Function ended, x invalid, followed by s. However, s has been moved, so it does not need to be released
Fn takes_ Ownership (some_string: String){
//A String parameter some_ String passed in, valid
Println! ({} ", some_string);
}//Function ended, parameter some_ String is released here
Fn makes_ Copy (some_integer: i32){
//An i32 parameter some_ Incoming integer, valid
Println! ({} ", some_integer);
}//Function ended, parameter some_ Integer is a basic type and does not need to be released

7.11.8. Ownership mechanism of function return value #

Fn main(){
Let s1=gifts_ Ownership();
//Gives_ Ownership moves its return value to s1
Let s2=String:: from ("hello");
//S2 declared valid
Let s3=takes_ And_ Gives_ Back (s2);
//S2 is moved as a parameter, and s3 obtains ownership of the return value
}//s3 is invalid and released, s2 is moved, and s1 is invalid and released
Fn gifts_ Ownership() ->String{
Let some_ String=String:: from ("hello");
//Some_ String declared valid
Return some_ String;
//Some_ String is moved out of the function as a return value
}
Fn takes_ And_ Gives_ Back (a_string: String) ->String{
//A_ String declared valid
A_ String//a_ String is used as a return value to move out of the function
}

7.11.9. Citation and lease #

Reference is a concept that C++ developers are familiar with.

If you are familiar with the concept of pointer, you can think of it as a pointer.

In essence, “reference” is the indirect access to variables.

fn main() {
    let s1 = String::from("hello");
    let s2 = &s1;
    println!("s1 is {}, s2 is {}", s1, s2);
}

s1 is hello, s2 is hello

fn main() {
    let s1 = String::from("hello");
    let len = calculate_length(&s1);
    println!("The length of '{}' is {}.", s1, len);
}
fn calculate_length(s: &String) -> usize {
    s.len()
}

The length of 'hello' is 5.

fn main() {
    let s1 = String::from("hello");
    let s2 = &s1;
    let s3 = s1;
    println!("{}", s2);
}

fn main() {
    let s1 = String::from("hello");
    let mut s2 = &s1;
    let s3 = s1;
    s2 = &s3; // Renting ownership from s3
    println!("{}", s2);
}

fn main() {
    let s1 = String::from("run");
    let s2 = &s1;
    println!("{}", s2);
    s2.push_str("oob"); // Error, it is prohibited to modify the rental value
    println!("{}", s2);
}

fn main() {
    let mut s1 = String::from("run");
    // S1 is variable
    let s2 = &mut s1;
    // S2 is a variable reference
    s2.push_str("oob");
    println!("{}", s2);
}

let mut s = String::from("hello");
let r1 = &mut s;
let r2 = &mut s;
println!("{}, {}", r1, r2);

7.11.10. Dangling References #

This is a concept with a different name, and if you put it in a programming language with a pointer concept, it refers to a pointer that doesn’t actually point to data that can actually be accessed (note, it’s not necessarily a null pointer, it could also be a resource that has been released). They are like ropes that lose hanging objects, so they are called”hanging references”.

A “dangling reference” is not allowed in the Rust language, and if so, thecompiler will find it.

Here is a typical case of overhanging:

fn main() {
    let reference_to_nothing = dangle();
}
fn dangle() -> &String {
    let s = String::from("hello");
    &s
}