Hey!
I’m a professional software engineer with several years of experience using Rust. Unfortunately I don’t really have the time to contribute to Lemmy directly myself, but I love teaching other people Rust so if:
- You are curious about Rust and why you should even learn it
- You are trying to learn Rust but maybe having a hard time
- You are wondering where to start
- You ran into some specific issue
… or anything to do with Rust really, then feel free to ask in the comments or shoot me a PM 🙂
No. Not any practical difference at least. AFAIK behind the scenes, the const reference is just a const value that Rust automatically creates a reference to. So it’s just a matter of preference or what makes sense for your case.
I think I need to see an example of the function (or at least the signature) to give any concrete advice. It really depends on what you’re doing and what the function is.
Okay so there’s multiple things to unpack here. First of all, &str is a string slice, as you say. It is a “fat pointer”, as all slices are, with 2 components: A pointer to the data and a length.
However, &str does not say anything about whether or not the data that it points to or even the &str itself (pointer + length) is on the stack or not. The pointer inside the &str may point anywhere and there’s no guarantee that even the &str itself is on the stack (e.g. a
Box<&str>
is a &str on the heap and the pointer inside that &str could point anywhere).When you write a string literal like
"Hello world!"
, it is a&'static str
slice, where the &str itself (pointer + length) exists on the stack and the data that it points to is memory inside your final executable binary. But you can get &str’s from elsewhere, like a &str that refers to memory on the heap that doesn’t have a 'static lifetime.So when you write a string literal like you are in your consts there, you are not allocating any memory on the heap (in fact it is impossible to allocate memory on the heap in a const context). All you’re doing is adding a bit of string data to your final executable and that’s what the &str points to. To allocate, you would need to use a
String
.If all of your
Page
s are constant and you will write them out like this with literal strings, it’s not like there is any “problem”. However, you’ll only be able to makePage
s that can be defined at compile-time. Maybe that’s fine if all your pages are pre-defined ahead of time and doesn’t use any dynamic values or templating? If so, you can keep it like this in principle. You could even write the pages in a separate file and use theinclude_str!
macro to import them as a&'static str
as if you had written it out directly in your code.If you need just some
Page
s to have dynamic content, then you’ll need to either use aString
(which would make all of them heap-allocated) or you could use aCow
(clone-on-write pointer) which is an enum that can either be borrowed data like a&'static str
or owned data likeString
. Using Cow you could allow the static pages to not allocate while the dynamic ones do.No, cloning a &str does not clone the underlying text data. You can see this via a simple program:
fn main() { let s1 = "Example text"; let s2 = s1.clone(); println!("{s1:p}"); println!("{s2:p}"); }
The
:p
format specifier is the “pointer” specifier and will print the pointer of the string slice. If you run this, you’ll see that it prints the exact same pointer twice - i.e. boths1
ands2
are pointing to the exact same data (which only exists once).No reference counting is needed. Remember, Rust keeps track of reference lifetimes at compile-time. If you clone a
&'a str
then the clone is also a&'a str
. This is fine, it’s just another reference to the same string data and of course it has the same lifetime because it will be valid for just as long. Of course it’s valid for just as long, it’s pointing to the same data after all.Note that mutable references cannot be cloned, as that would allow multiple mutable references to the same data and that’s not allowed.
Note that dropping (“deleting” is not a term used in Rust) a &str does not free the underlying memory. It is just a reference after all, it doesn’t own the memory underneath.
If the body is a
&str
, then it will only clone the reference and the string data itself will not be copied, so this shouldn’t be an issue. But remember as I said above that this might only be true if your pages are indeed defined ahead-of-time and don’t need dynamic memory allocation.I can give more concrete advice if you give more code and explain your use case more thoroughly (see also XY problem).
Thanks for the great reply! (And sorry for that other complicated question… )
Knowing that &str is just a reference, makes sense when they are limited to compile time. The compiler naturally knows in that case when it’s no longer used and can drop the string at the appropriate time. Or never dropped in my case, since it’s const.
Since I’m reading files to serve webpages, I will need Strings. I just didn’t get far enough to learn that yet… and with that ‘Cow’ might be a good solution to having both. Just for a bit of extra performance when some const pages are used a lot.
For example code, here’s a function. Simply take a page, and constructs html from a template, where my endpoint is used in it.
pub fn get_full_page(&self, page: &Page) -> String { self.handler .render( PageType::Root.as_str(), &json!({"content-target": &page.endpoint}), ) .unwrap_or_else(|err| err.to_string()) }
Extra redundant context: All this is part of a blog I’m making from scratch. For fun and learning Rust, and Htmx on the browser side. It’s been fun finding out how to lazy load images, my site is essentially a single paged application until you use “back” or refresh the page. The main content part of the page is just replaced when you click a “link”. So the above function is a “full serve” of my page. Partial serving isn’t implemented using the Page structs yet. It just servers files at the moment. When the body is included, which would be the case for partial serves i’ll run into that &str issue.
Cool, sounds like you have a lot of fun learning :)