Where values live

Look at two names in Chatterbox's main as lesson 3.4 left it. messages_seen is a u32: 4 bytes (lesson 2.4), whether it holds 0 or four billion. line is a String holding whatever you typed: 3 bytes for hi and the Enter key (4 on Windows, where Enter adds two bytes), hundreds for a pasted paragraph.

The program was compiled long before you typed anything, so how did it make room for words it had never seen? A running program keeps values in two places, and one question decides which: is the size known before the program runs? Every rule in this chapter is about the second place.

A computer's working memory is one enormous row of tiny boxes. Each box holds one byte, a number from 0 to 255, and has a number of its own, its position in the row, called its address. That is all memory is. A u32 is four boxes side by side; the letter h is one box holding 104.

A value that says where another value is, by holding its address, is a pointer. On a 64-bit computer, which is nearly every laptop and phone today, an address is 8 bytes. Keep that number in mind.

Every time a function is called, it gets a frame: a small block of memory with one slot for each of its variables. Frames pile on top of each other, which is why this place is called the stack. When main calls reply, a frame for reply goes on top of main's; when reply returns, its frame comes off and every slot in it is gone at once. A frame is pushed, then popped.

That is fast: making room is moving one marker up, giving it back is moving it down. The condition is strict, though. The compiler plans each frame while compiling, so it must know every slot's size in advance. A u32 slot is 4 bytes, always. A slot that might need 3 bytes or 3,000, depending on what somebody types, cannot be planned.

Try to break that rule. [0; 5] is an array of five zeros (arrays are from lesson 3.3), and an array sits right inside the frame. What if its length comes from text the program has just measured?

error[E0435]: attempt to use a non-constant value in a constant
 --> src/main.rs:4:22
  |
4 |     let buffer = [0; size];
  |                      ^^^^ non-constant value
  |
help: consider using `const` instead of `let`
  |
3 -     let size = typed.len();
3 +     const size: /* Type */ = typed.len();
  |

The second place is the heap: a large area of memory a program can ask for pieces of while it runs, of whatever size it needs right then. Asking is called allocating: the allocator finds a free block of the right size and hands back its address, and when the program has finished with the block, it hands it back for reuse.

That costs more than the stack, because finding a block takes work and every block must be handed back exactly once. In return the heap can hold something whose size is only known at run time, and that may grow later.

A String uses both places. Its text lives in a heap block. In the frame sits a fixed part of three numbers: a pointer to the text's first byte, the length (bytes of text now, what len() reports) and the capacity (bytes the block has room for). Three times 8 bytes is 24 bytes, whether the text is empty or a novel. So line got a slot in main's frame although nobody knew what you would type: the slot holds directions to the text, not the text.

A &str (lesson 2.5) is the same idea with one number fewer: a pointer and a length, 16 bytes, looking at text that lives elsewhere, in a String's heap block or inside the program for quoted text. It never grows, so it needs no capacity.

You can measure these yourself with size_of, a function from Rust's standard library that reports how many bytes a type takes in a frame. Its question is about a type, not a value, so the type is not passed in the round brackets (they stay empty). It goes in angle brackets straight after the name, joined by ::: size_of::<String>() reads as "size_of, for String". The use std::mem::size_of; line brings the function into reach, the way use std::io; did in lesson 3.4. Guess what this prints.

Step through a small program. On the right, frames stack up from main's, with heap blocks beside them. A solid arrow from a slot to a block is a String's pointer.

Notice the difference. Frames were made and thrown away whole, for free. The heap block had to be asked for, asked for again when the text grew, and handed back at the end. That last part must happen exactly once: never, and the memory is lost (a leak); twice, and the program can crash. Here it went back because line was responsible for it. How Rust decides who is responsible is the next lesson.

Here is main from Chatterbox v0.3, after you typed Sam as your name and hello as a message.

Two things in code you already have make sense now.

• Why line is made once, before the loop. line.clear() sets the length to 0 but keeps the heap block. So every line you type is read into the same block, and the allocator is asked again only when a line is longer than any before. A new String inside the loop would ask for a block and hand it back every turn.
• Why trim() costs nothing. name and message are &strs that look at part of name_line's and line's text, skipping what trim cut off. No text is copied.

Which raises a question. message points into line's heap block. What if that block were cleared or handed back while message still pointed there? In many languages that is a bug you find months later. In Rust it does not compile, and the next five lessons are why.

Sources The Rust Book: What Is Ownership? (the stack and the heap) · std::string::String (representation: pointer, length, capacity) · std::mem::size_of · Rust error index: E0435