I am currently new to the language but i am kinda stuck to certain things.
In rust i figured out that there are two general ways of declaring a string type thing.
let l: String = Strings::from(“hello”);
Now where l is struct containing pointer(to the heap), len of the string and capacity of the heap. it makes is a mutable type things.
Now, let l: &str = “hello”;
make “hello“ hardcoded in memory.
now as l is &str type doesn’t it makes it a pointer? and if it’s pointer shouldn’t i use *l to derefrence it and print is on the screen with println!
Also is this code too which wrote
use std::collections::HashSet;
fn main() {
let text: String = String::from("leet code");
let broken_letters: String = String::from("e");
println!("{}", can_be_typed_words(text, broken_letters));}
fn can_be_typed_words(text: String, broken_letters: String) -> i32 {
let _bl: HashSet = broken_letters.chars().collect();
let t: Vec<&str> = text.split_whitespace().collect();
for i in t {println!("{}", i);}12}
Now _bl would be {‘e’} and t = [“leet“, “code”]in the for loop if i use just “t“ or “&t“ both of them works fine and give me the same result, there should be something different. I think an error should be there as &t is referecing toward the address where the array start.
if someone can really help me out in these concepts i guess i would be able to understand rust in a much better way.
It is a fat pointer, with length and start address:
fn main(){
let a = String::from("hello");
println!("{}", std::mem::size_of_val(&a)); //24 (3 u64)
let b:&str = &a;// nevermind the coercion, we have &str type.
println!("{}", std::mem::size_of_val(&b)) //16 (2 u64)
}
It dereferences for you when needed. You can also print a println!("{}",&5)and if you want the pointer you can print it as println!("{:p}", my_ref)
println! is defined in terms of the Display trait, and that trait is implemented both for str and for any &T where T itself implements Display, which would then naturally include &str. Since &str implements Display, you don’t need to dereference it to str before passing it to println!.
Having said that, yes, somewhere along the line the machinery involved in printing a string to standard output will inevitably have to follow the pointer contained in the &str value to find the actual characters to print. It’s just that the standard library takes care of that for you, so that you don’t have to.
For loops are defined in terms of the IntoIterator trait. That trait is implented for both Vec<T>, producing an Iterator<Item=T>, and for &Vec<T>, producing an Iterator<Item=&T>. Your loop happens to work fine with both, since both a &str and an &&str can be passed to println!: as above, &&str implements Display because &str implements Display because str implements Display, so it doesn’t matter for your program whether the i from for i in t has type &str, or type &&str (due to for i in &t).
Repeating what others said with different words: str, &str, &&str, ... &&&&&&&&&str all print the same (via the Display trait). And the same goes for any other value and references to values that can be printed.
This is only one example of a trait where references implement the trait by dispatching to the referent.
(Incidentally, as a macro, println! can do many things not evident from the calling syntax. It happens to implicitly take references to all its to-be-printed arguments.)