From 3ae40782ec7af5b157afc9042ffb63c2248307ae Mon Sep 17 00:00:00 2001 From: Ralf Biedert Date: Mon, 27 Jul 2020 10:12:27 +0200 Subject: [PATCH] More intro ... I think we're done ... also closes #93 and hopefully makes #57 even more so. --- content/_index.md | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/content/_index.md b/content/_index.md index daad12e..104656c 100644 --- a/content/_index.md +++ b/content/_index.md @@ -740,13 +740,23 @@ Why moves, references and lifetimes are how they are. -- Application memory is a large array of unstructured bytes. -- Memory is segmented, amongst others, into: - - **stack** (most variables go here), +- Application memory in itself is just array of bytes. +- It is segmented, amongst others, into: + - **stack** (small, low-overhead memory,1 most _variables_ go here), - **heap** (large, flexible memory, but always handled via stack proxy like `Box`), - - **static** (most commonly used as resting place for `str` part of `&str`). -- Most real magic happens on stack, which is our focus. + - **static** (most commonly used as resting place for `str` part of `&str`), + - **code** (where bitcode of your functions reside). +- Programming languages such as Rust give developers tools to: + - define what data goes into what segment, + - express a desire for bitcode with specific properties to be produced, + - protect themselves from errors while performing these operations. +- Most tricky part is tied to **how stack evolves**, which is **our focus**. +
+ +1 While for each part of the heap someone (the allocator) needs to perform bookkeeping at runtime, the stack is trivially managable: _take a few bytes more while you need them, they will be discarded once you leave_. The (for performance reasons desired) simplicity of this appraoch, along with the fact that you can tell others about such _transient_ locations (which in turn might want to access them long after you left), form the very essence of why _lifetimes_ exist; and are the subject of the rest of this chapter. + +