How Long Live for &'static str

help
1

I have a question about, if &'static str live in whole proggram life time, then, I created much &'static str, do meaning mem leak?

&'static str never drop?

2

No, you're not creating a memory leak - it simply means that the str is available for the entire lifetime of the program.
Internally, it means that the string constant is stored directly in the executable (the .rodata section typically on Linux).

3

It depends on how you created the &'static str. If you create many string literals, those will be baked into the executable. That doesn't count as a memory leak.

If you explicitly leak memory, by e.g. calling Box<str>::leak(), then, well, you did indeed leak memory with those instances. That's probably not what you are doing, though.

3 Likes
4

&'static references can be created in two ways: by hardcoding something - then it is not leaked, but stored as part of the program; and, yes, leaking memory, but it will always be explicit.

&'static reference guarantees that the object it points to is alive until the end of the program, yes.
It's not correct to speak about "dropping &'static str", since shared references are Copy, and therefore are never dropped (their destruction is just a stack memory deallocation). The value behind them, however, will not be dropped, even if it has drop glue, that's correct.

5

thanks for your ask much.

another question that i create a random string func like

fun random() -> &'static str

it's mem leak. i should return String more better.

6

Yes, because without explicitly calling something like Box::leak inside this function it would not compile.

For runtime-generated values - yes, owned values are usually better. Non-static references are an optimization, not a necessity, and they are non-trivial to do right.

7

Yes. It's better to use String and clone unless you are writing something really performance or memory critical.

It's doable but would mean that you would spend 10x times more on coding. Rarely justified. Mistake #7 in the well-known list.

What does work, though, is to first write working code with lots of Strings and clones and then looking on what you made and replacing some of these to &str. Usually you can get pretty awesome memory and performance savings easily but last 20% are nightmare to achieve… and are usually not worth it.

8

Well it depends on how you implement it. The following function that returns a random string consisting of a single letter would normally not be considered a memory leak:

fn random() -> &'static str {
    let letters = "abcdefghijklmnopqrstuvwxyz";
    let idx = random_int(letters.len());
    &letters[idx..idx+1]
}

On the other hand, if you implement it by calling creating a new String and using the Box::leak method to leak it, well, then you've leaked memory.

So the &'static str type only corresponds to a memory leak if you need to be able to create the string data after starting the program. Taking a substring of a hard-coded string in your source code, or selecting one hard-coded string from a list, would all be non-leaking ways to create a &'static str.

4 Likes
9

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.