{"id":404262,"date":"2024-06-29T17:36:17","date_gmt":"2024-06-29T17:36:17","guid":{"rendered":"http:\/\/savepearlharbor.com\/?p=404262"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-29T21:00:00","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=404262","title":{"rendered":"How does Rust treat Strings and Vectors internally<\/span>"},"content":{"rendered":"
<\/div>\n
\n
\n
\n
\n

1. Strings<\/h2>\n

In Rust strings can be represented in two ways:<\/p>\n

a)\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 String type <\/p>\n

b)\u00a0\u00a0\u00a0\u00a0\u00a0 String slice<\/p>\n

String type:<\/strong><\/p>\n

String type is defined as a struct of the following structure:<\/p>\n

Depending on arch (in my case x86 64bit it is 24byte)<\/p>\n

{<\/em><\/p>\n

\u00a0\u00a0 pointer to the address where string characters are stored (8b)<\/em><\/p>\n

\u00a0\u00a0 capacity (8b)<\/em><\/p>\n

\u00a0\u00a0 length (8b)<\/em><\/p>\n

}<\/em><\/p>\n

\u00a0<\/em>Example:<\/p>\n

let my_string = String::from(\"hello\");<\/code><\/pre>\n
String slice (String slice has type &str):<\/strong><\/p>\n
There are two types of slices:<\/p>\n
a)\u00a0\u00a0\u00a0\u00a0\u00a0 built from Strings<\/em><\/strong><\/p>\n
let my_string_slice = &my_string[3..];<\/code><\/pre>\n
The goal of such slice is to point on some part of the string<\/p>\n
The structure of such slice similar to String:<\/p>\n
{<\/em><\/p>\n
\u00a0\u00a0 pointer to the address where string characters are stored (8b)<\/em><\/p>\n
\u00a0\u00a0 length (8b)<\/em><\/p>\n
\u00a0\u00a0 starting index (8b)<\/em><\/p>\n
}<\/em><\/p>\n
b)\u00a0\u00a0\u00a0\u00a0\u00a0 built from string literals<\/em><\/strong><\/p>\n
let my_str = \"Hello\";<\/code><\/pre>\n
It has reduced size:<\/p>\n
{<\/em><\/p>\n
\u00a0\u00a0 pointer to the address where string characters are stored (8b)<\/em><\/p>\n
\u00a0\u00a0 length (8b)<\/em><\/p>\n
}<\/em><\/p>\n
Memory layout:<\/strong><\/p>\n
So let\u2019s have a look how does these two types lays on memory:<\/p>\n
Let\u2019s consider couple definitions:<\/p>\n
let my_str :&str = \"hello\"; let my_string1: String = my_str.to_string(); let my_string2: String = String::from(\"hello\"); let my_string_slice: &str = &my_string2[1..4];<\/code><\/pre>\n
We have defined 4 local variables:<\/p>\n
my_str \u2013 is a slice defined from string literals \u201chello\u201d. Such string literals are part of the code(data segment more precisely)<\/p>\n
my_string1 \u2013 result of creation String from the slice using to_string method;<\/p>\n
my_string2 \u2013 string creation using from method.<\/p>\n
my_string_slice \u2013 slice from string<\/p>\n
\u00a0The following picture shows memory layout for each variable:<\/p>\n
<\/figcaption><\/figure>\n
As you can see first variable(&str) is created in stack and pointing to the static location of our code where string literals of \u201chello\u201d are placed<\/p>\n
Then when we call to_string() the new variable my_string1 is created and memory on heap is allocated to place \u201chello\u201d chars there.<\/p>\n
Same happens when we create my_string2 variable.<\/p>\n
Creation of my_string_slice from my_string2 leads to pointing to the same area in heap where my_string2 characters are placed but with shift in address considering starting index<\/p>\n
2.\u00a0\u00a0\u00a0\u00a0 Vectors<\/h2>\n
Vectors in rust are dynamically extended data structures;<\/p>\n
They have similar structure as String:<\/p>\n
{<\/em><\/p>\n
\u00a0\u00a0 pointer to the address in the heap where data are stored (8b)<\/em><\/p>\n
\u00a0\u00a0 capacity (8b)<\/em><\/p>\n
\u00a0\u00a0 length (8b)<\/em><\/p>\n
}<\/em><\/p>\n
Let\u2019s have a look what happens when we create new vector and push some data to it (continue of the previous example with strings).<\/p>\n
let mut str_vec = Vec::new(); str_vec.push(my_string1); str_vec.push(my_string2);<\/code><\/pre>\n
<\/figcaption><\/figure>\n
So as we see when we created str_vec variable of type Vec<String> the new memory were allocated in heap. To be more precise during variable creation using new() method pointer of the vector doesn\u2019t point to real heap space. This happen only with first push:<\/p>\n
Memory dump:<\/p>\n
let mut str_vec = Vec::new();<\/code><\/pre>\n
pointer = 0x3a772ff2f8 (&str_vec<\/u>)<\/p>\n
08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<\/p>\n
str_vec.push(my_string1);<\/code><\/pre>\n
50 5e ca db db 01 00 00 04 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00<\/p>\n
str_vec.push(my_string2);<\/code><\/pre>\n
50 5e ca db db 01 00 00 04 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00<\/p>\n
So as you can see real address pointing to the heap(0x000001dbdbca5e50) appears only after first push. Initial capacity 4 is reserved at this time as well. When more the 4 elements will be pushed the new area will be allocated with extended size.<\/p>\n
\u00a0When my_string1<\/em> and my_string2<\/em> were pushed to the vector two things happened:<\/p>\n
1)\u00a0\u00a0\u00a0\u00a0\u00a0 Memory allocation in heap for storing two string variables. Pay attention that pointers of the strings still point to same addresses were chars were stored.<\/p>\n
2)\u00a0\u00a0\u00a0\u00a0\u00a0 Move of ownership: my_string<\/em>1 and my_string<\/em>2 are no more accessible as local variables. (see more details from official rust tutorial regarding transfer ownership). Moving variables to heap space is shown with dot arrow on the pic.<\/p>\n
3.\u00a0\u00a0\u00a0\u00a0 Magic transformation during procedure call<\/h2>\n
Let\u2019s consider the following code:<\/p>\n
fn main() {     let args: Vec<String> = env::args().collect();      let ptr: *mut u8 = unsafe { mem::transmute(&args) };     print_mem(ptr, 24 );      let (query, filename) = parse_config(&args); }  fn parse_config(args: &[String]) -> (&str, &str) {     println!(\"args val {:p}\", args);      let query = &args[1];     let filename = &args[2];      (query, filename) }<\/code><\/pre>\n
Here we can see declaration of vector \u00a0variable \u201cargs\u201d that takes incoming parameters of main function in vector format.<\/p>\n
let args: Vec<String> = env::args().collect();<\/code><\/pre>\n
As result we have local variable \u201cargs\u201d created on stack.<\/p>\n
Let\u2019s print it\u2019s content (execute the program with two args: cargo run param1 param2):<\/p>\n
let ptr: *mut u8 = unsafe { mem::transmute(&args) }; print_mem(ptr, 24 );<\/code><\/pre>\n
pointer = 0xfa9a4ff730<\/p>\n
40 2a 6f b3 6a 02 00 00 03 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00<\/p>\n
So as we can see \u201cargs\u201d has three parts: <\/p>\n
1)\u00a0\u00a0\u00a0\u00a0\u00a0 Pointer to heap 0x26ab36f2a40 where strings with argument values are allocated<\/p>\n
2)\u00a0\u00a0\u00a0\u00a0\u00a0 Capacity of the vector (03)<\/p>\n
3)\u00a0\u00a0\u00a0\u00a0\u00a0 Length of the vector (03)<\/p>\n
Now let\u2019s have a look at function call:<\/p>\n
let (query, filename) = parse_config(&args);<\/code><\/pre>\n
and function definition:<\/p>\n
fn parse_config(args: &[String]) -> (&str, &str) { \u2026 }<\/code><\/pre>\n
You can notice some mismatch in calling params type and param definition in function.<\/p>\n
The function is defined with &[String])<\/em><\/strong> parameter but is called with address of local variable \u201cargs\u201d that has Vec<String><\/em><\/strong> type.<\/p>\n
So let\u2019s try to understand how it can be?<\/p>\n
Here some magic of rust compiler happens: as \u201cargs\u201d variable in main function is local variable it\u2019s address itself(address in stack) is not transferred to calling function (actually technically it can be but not done in this way) overwise compiler analyze that expected param of calling function is address of String array &[String]<\/em><\/strong>)<\/em> and sends address of start of String array in heap where pointer in \u201cargs\u201d is referring(0x26ab36f2a40 in our example)<\/p>\n
We can see it if will print value of \u00a0incoming parameter \u201cargs\u201d in parse_config function:<\/p>\n
println!(\"args val {:p}\", args);<\/code><\/pre>\n
output: 0x26ab36f2a40<\/p>\n
Note: in rust it is called «Implicit Deref Coercions with Functions and Methods». It is related to Deref trait and you can read about it in more details from official tutorial.<\/em><\/strong><\/p>\n<\/div>\n<\/div>\n<\/div>\n
<\/div>\n

 \u0441\u0441\u044b\u043b\u043a\u0430 \u043d\u0430 \u043e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0441\u0442\u0430\u0442\u044c\u0438  https:\/\/habr.com\/ru\/articles\/657547\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
<\/div>\n
\n
\n
\n
\n
1. Strings<\/h2>\n
In Rust strings can be represented in two ways:<\/p>\n
a)\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 String type <\/p>\n
b)\u00a0\u00a0\u00a0\u00a0\u00a0 String slice<\/p>\n
String type:<\/strong><\/p>\n
String type is defined as a struct of the following structure:<\/p>\n
Depending on arch (in my case x86 64bit it is 24byte)<\/p>\n
{<\/em><\/p>\n
\u00a0\u00a0 pointer to the address where string characters are stored (8b)<\/em><\/p>\n
\u00a0\u00a0 capacity (8b)<\/em><\/p>\n
\u00a0\u00a0 length (8b)<\/em><\/p>\n
}<\/em><\/p>\n
\u00a0<\/em>Example:<\/p>\n
let my_string = String::from(\"hello\");<\/code><\/pre>\n
String slice (String slice has type &str):<\/strong><\/p>\n
There are two types of slices:<\/p>\n
a)\u00a0\u00a0\u00a0\u00a0\u00a0 built from Strings<\/em><\/strong><\/p>\n
let my_string_slice = &my_string[3..];<\/code><\/pre>\n
The goal of such slice is to point on some part of the string<\/p>\n
The structure of such slice similar to String:<\/p>\n
{<\/em><\/p>\n
\u00a0\u00a0 pointer to the address where string characters are stored (8b)<\/em><\/p>\n
\u00a0\u00a0 length (8b)<\/em><\/p>\n
\u00a0\u00a0 starting index (8b)<\/em><\/p>\n
}<\/em><\/p>\n
b)\u00a0\u00a0\u00a0\u00a0\u00a0 built from string literals<\/em><\/strong><\/p>\n
let my_str = \"Hello\";<\/code><\/pre>\n
It has reduced size:<\/p>\n
{<\/em><\/p>\n
\u00a0\u00a0 pointer to the address where string characters are stored (8b)<\/em><\/p>\n
\u00a0\u00a0 length (8b)<\/em><\/p>\n
}<\/em><\/p>\n
Memory layout:<\/strong><\/p>\n
So let\u2019s have a look how does these two types lays on memory:<\/p>\n
Let\u2019s consider couple definitions:<\/p>\n
let my_str :&str = \"hello\"; let my_string1: String = my_str.to_string(); let my_string2: String = String::from(\"hello\"); let my_string_slice: &str = &my_string2[1..4];<\/code><\/pre>\n
We have defined 4 local variables:<\/p>\n
my_str \u2013 is a slice defined from string literals \u201chello\u201d. Such string literals are part of the code(data segment more precisely)<\/p>\n
my_string1 \u2013 result of creation String from the slice using to_string method;<\/p>\n
my_string2 \u2013 string creation using from method.<\/p>\n
my_string_slice \u2013 slice from string<\/p>\n
\u00a0The following picture shows memory layout for each variable:<\/p>\n
<\/figcaption><\/figure>\n
As you can see first variable(&str) is created in stack and pointing to the static location of our code where string literals of \u201chello\u201d are placed<\/p>\n
Then when we call to_string() the new variable my_string1 is created and memory on heap is allocated to place \u201chello\u201d chars there.<\/p>\n
Same happens when we create my_string2 variable.<\/p>\n
Creation of my_string_slice from my_string2 leads to pointing to the same area in heap where my_string2 characters are placed but with shift in address considering starting index<\/p>\n
2.\u00a0\u00a0\u00a0\u00a0 Vectors<\/h2>\n
Vectors in rust are dynamically extended data structures;<\/p>\n
They have similar structure as String:<\/p>\n
{<\/em><\/p>\n
\u00a0\u00a0 pointer to the address in the heap where data are stored (8b)<\/em><\/p>\n
\u00a0\u00a0 capacity (8b)<\/em><\/p>\n
\u00a0\u00a0 length (8b)<\/em><\/p>\n
}<\/em><\/p>\n
Let\u2019s have a look what happens when we create new vector and push some data to it (continue of the previous example with strings).<\/p>\n
let mut str_vec = Vec::new(); str_vec.push(my_string1); str_vec.push(my_string2);<\/code><\/pre>\n
<\/figcaption><\/figure>\n
So as we see when we created str_vec variable of type Vec<String> the new memory were allocated in heap. To be more precise during variable creation using new() method pointer of the vector doesn\u2019t point to real heap space. This happen only with first push:<\/p>\n
Memory dump:<\/p>\n
let mut str_vec = Vec::new();<\/code><\/pre>\n
pointer = 0x3a772ff2f8 (&str_vec<\/u>)<\/p>\n
08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<\/p>\n
str_vec.push(my_string1);<\/code><\/pre>\n
50 5e ca db db 01 00 00 04 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00<\/p>\n
str_vec.push(my_string2);<\/code><\/pre>\n
50 5e ca db db 01 00 00 04 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00<\/p>\n
So as you can see real address pointing to the heap(0x000001dbdbca5e50) appears only after first push. Initial capacity 4 is reserved at this time as well. When more the 4 elements will be pushed the new area will be allocated with extended size.<\/p>\n
\u00a0When my_string1<\/em> and my_string2<\/em> were pushed to the vector two things happened:<\/p>\n
1)\u00a0\u00a0\u00a0\u00a0\u00a0 Memory allocation in heap for storing two string variables. Pay attention that pointers of the strings still point to same addresses were chars were stored.<\/p>\n
2)\u00a0\u00a0\u00a0\u00a0\u00a0 Move of ownership: my_string<\/em>1 and my_string<\/em>2 are no more accessible as local variables. (see more details from official rust tutorial regarding transfer ownership). Moving variables to heap space is shown with dot arrow on the pic.<\/p>\n
3.\u00a0\u00a0\u00a0\u00a0 Magic transformation during procedure call<\/h2>\n
Let\u2019s consider the following code:<\/p>\n
fn main() {     let args: Vec<String> = env::args().collect();      let ptr: *mut u8 = unsafe { mem::transmute(&args) };     print_mem(ptr, 24 );      let (query, filename) = parse_config(&args); }  fn parse_config(args: &[String]) -> (&str, &str) {     println!(\"args val {:p}\", args);      let query = &args[1];     let filename = &args[2];      (query, filename) }<\/code><\/pre>\n
Here we can see declaration of vector \u00a0variable \u201cargs\u201d that takes incoming parameters of main function in vector format.<\/p>\n
let args: Vec<String> = env::args().collect();<\/code><\/pre>\n
As result we have local variable \u201cargs\u201d created on stack.<\/p>\n
Let\u2019s print it\u2019s content (execute the program with two args: cargo run param1 param2):<\/p>\n
let ptr: *mut u8 = unsafe { mem::transmute(&args) }; print_mem(ptr, 24 );<\/code><\/pre>\n
pointer = 0xfa9a4ff730<\/p>\n
40 2a 6f b3 6a 02 00 00 03 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00<\/p>\n
So as we can see \u201cargs\u201d has three parts: <\/p>\n
1)\u00a0\u00a0\u00a0\u00a0\u00a0 Pointer to heap 0x26ab36f2a40 where strings with argument values are allocated<\/p>\n
2)\u00a0\u00a0\u00a0\u00a0\u00a0 Capacity of the vector (03)<\/p>\n
3)\u00a0\u00a0\u00a0\u00a0\u00a0 Length of the vector (03)<\/p>\n
Now let\u2019s have a look at function call:<\/p>\n
let (query, filename) = parse_config(&args);<\/code><\/pre>\n
and function definition:<\/p>\n
fn parse_config(args: &[String]) -> (&str, &str) { \u2026 }<\/code><\/pre>\n
You can notice some mismatch in calling params type and param definition in function.<\/p>\n
The function is defined with &[String])<\/em><\/strong> parameter but is called with address of local variable \u201cargs\u201d that has Vec<String><\/em><\/strong> type.<\/p>\n
So let\u2019s try to understand how it can be?<\/p>\n
Here some magic of rust compiler happens: as \u201cargs\u201d variable in main function is local variable it\u2019s address itself(address in stack) is not transferred to calling function (actually technically it can be but not done in this way) overwise compiler analyze that expected param of calling function is address of String array &[String]<\/em><\/strong>)<\/em> and sends address of start of String array in heap where pointer in \u201cargs\u201d is referring(0x26ab36f2a40 in our example)<\/p>\n
We can see it if will print value of \u00a0incoming parameter \u201cargs\u201d in parse_config function:<\/p>\n
println!(\"args val {:p}\", args);<\/code><\/pre>\n
output: 0x26ab36f2a40<\/p>\n
Note: in rust it is called «Implicit Deref Coercions with Functions and Methods». It is related to Deref trait and you can read about it in more details from official tutorial.<\/em><\/strong><\/p>\n<\/div>\n<\/div>\n<\/div>\n
<\/div>\n

 \u0441\u0441\u044b\u043b\u043a\u0430 \u043d\u0430 \u043e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0441\u0442\u0430\u0442\u044c\u0438  https:\/\/habr.com\/ru\/articles\/657547\/<\/a>
<\/br><\/br><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-404262","post","type-post","status-publish","format-standard","hentry"],"_links":{"self":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/404262","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=404262"}],"version-history":[{"count":0,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/404262\/revisions"}],"wp:attachment":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=404262"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=404262"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=404262"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}