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 🙂

  • BehindTheBarrier@programming.devEnglish
    2·
    7 months ago

    Hi,

    Learning Rust and getting caught up in details, but I always want to know the whys of things, and the minor differences.

    Lets start of with, is there a difference between the const value vs const reference?

    // Given this little struct of mine, a Page with information about an endpoint
#[derive(Clone)]
pub struct Page<'a> {
    pub title: &'a str,
    pub endpoint: &'a str,
}

// Value
const ROOT_PAGE: Page = Page::new("Home", "/home");

// Reference
const ROOT_PAGE: &'static Page = &Page::new("Home", "/home");

    1. Since my functions always take a reference, is there any advantage to any of them. References are read-only, but since it’s const it probably doesn’t matter. What is prefered?

    2. I know String does allocations, while &str is a string slice or something which may be on the stack. Do I not end up making any allocations in this case since stucts are on the stack by default, and only hold the pointers to a string “slice”. Especially given how they are made in this case.

    3. Is structs with references like this okay, this Page is constant but I’m going to make many “Pages” later based on the pages my blog has, as well as some other endpoints of course.

    4. If the struct is cloned, is the entire string as well, or just the pointer to the string slice? I assume it does copy the entire string, since to the best of my knowledge a &str does not do any reference counting, so deleting a &str means deleting it’s content, not just the reference. Since that is the case, a clone will also copy the string.

    5. I am contemplating adding a “body” string to my Page struct. These string will of course be large and vary depending on the page. Naturally, I do not want to end up copying the entire body string every time the Page is cloned. What is the best course here, it kind of depends on the previous question, but is an Arc the solution here? There is only reading to be done from them, so I do not need to worry about any owner holding it.

    • SorteKaninOPAEnglish
      2·
      7 months ago

      Lets start of with, is there a difference between the const value vs const reference?

      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.

      1. Since my functions always take a reference, is there any advantage to any of them. References are read-only, but since it’s const it probably doesn’t matter. What is prefered?

      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.

      1. I know String does allocations, while &str is a string slice or something which may be on the stack. Do I not end up making any allocations in this case since stucts are on the stack by default, and only hold the pointers to a string “slice”. Especially given how they are made in this case.

      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.

      1. Is structs with references like this okay, this Page is constant but I’m going to make many “Pages” later based on the pages my blog has, as well as some other endpoints of course.

      If all of your Pages 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 make Pages 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 the include_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 Pages to have dynamic content, then you’ll need to either use a String (which would make all of them heap-allocated) or you could use a Cow (clone-on-write pointer) which is an enum that can either be borrowed data like a &'static str or owned data like String. Using Cow you could allow the static pages to not allocate while the dynamic ones do.

      1. If the struct is cloned, is the entire string as well, or just the pointer to the string slice? I assume it does copy the entire string, since to the best of my knowledge a &str does not do any reference counting, so deleting a &str means deleting it’s content, not just the reference. Since that is the case, a clone will also copy the string.

      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. both s1 and s2 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.

      1. I am contemplating adding a “body” string to my Page struct. These string will of course be large and vary depending on the page. Naturally, I do not want to end up copying the entire body string every time the Page is cloned. What is the best course here, it kind of depends on the previous question, but is an Arc the solution here? There is only reading to be done from them, so I do not need to worry about any owner holding it.

      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).

      • BehindTheBarrier@programming.devEnglish
        2·
        7 months ago

        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.

        • SorteKaninOPAEnglish
          1·
          7 months ago

          Cool, sounds like you have a lot of fun learning :)