&str vs String for HashMap key

help
21

Just wanted to thank you for the hint about leak()! Yes, "leaking" the string and specifying a lifetime for &str works just fine for my test case.

22

@abmpicoli

You seem to have a misconception about String:

Putting a String into a HashMap will not clone the string. It moves the String that contains a pointer to the actual characters of the string. The characters do not get copied when you move a String.

1 Like
23

Not in the hashmap itself, no. But for populating the hashmap, yes.

You end up always doing something like

String::from()... or String.clone(), due to the lifetimes and borrowing issues.

But I'm starting to feel ok with it. So, well, whatever :slight_smile:

1 Like
24

If you want to store references to strings borrowed from elsewhere, you do HashMap<&str, i32>.
If you want to store strings owned by the hash map, you do HashMap<String, i32>.
If you want to store a mix of both, you can do:

let mut h: HashMap<Cow<str>, i32> = HashMap::new();
h.insert(Cow::Borrowed("blue"), 12);
h.insert(Cow::Owned(String::from("yellow")), 13);
4 Likes
25

I see. Noob here following the book :slight_smile: . So, good to know there is this cow thing Cow in std::borrow - Rust .

Interesting , though, there is no reference in the Rust programming language book about it. Well, thanks for the hint. :slight_smile:

26

You have to draw the line somewhere. The Book was written to teach you to write Rust programs that work. Not teach you about all the idioms that are present in the standard library. At least it teaches you about entry (which both joy to use and also something you wouldn't easily find unless you know about it from tutorial).

That's another thing that is different about Rust: because writing efficient code is hard (it's always hard, not just in Rust!) and because Rust makes it very easy to refactor your code usually it's considered good idea to write something that works and then refactor it into perfect, idiomatic, code.

Or not rewrite if you don't have time.

It takes, literally, years to learn to write idiomatic code in Rustā€¦ and that's fine: idiomatic code may be easier to read and understand but your non-idiomatic code would still be pretty robust and you can refactor it later so please don't hesitate to start writing some real code once you'll finish the book.

Contrast it with languages like C++ or JavaScript (less so for Java or C#) where it's easy to write non-idiomatic code that would be so convoluted that no one would be able to untangle unholy mess and often your only option is to throw away that pile ofā€¦ code and start from scratch.

P.S. I often think that there are so many idioms in Rust simply because Rust may afford it: if code of novice is different from code of master but even novice delivers something that works then you add more and more idiomsā€¦ if everyone needs to use all the idioms from the very beginningā€¦ then you need to limit definition of what is ā€œidiomaticā€ or else newbies wouldn't be able to learn your language.

3 Likes
27

Well, sure. I'm going humble. And patient. If eventually I will get into a point of the book where I can do something equivalent to what a Cow does, or I can deal with hashmaps in the way I can deal with hashmaps in another languages, or how to implement the same structures, I'm ok with it.

Baby steps.

28

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.