Antwoord.

Geschiedenis van de vraag

In C/C++ en andere low-level talen moet de ontwikkelaar expliciet het geheugenbeheer regelen: op de stack (automatische variabelen) of op de heap (allocatie via malloc/new). In deze talen ontstaan vaak fouten met geheugenlekken, dubbele vrijgaven of het gebruik van niet-geïnitieerde of al vrijgegeven geheugen. Rust neemt de taak van strikte geheugentoewijzing op zich met behulp van een eigendomsysteem, zonder een garbage collector.

Probleem

Automatisch geheugenbeheer via de stack is handig, maar beperkt door de grootte (diepte van de stack). Allocatie op de heap vereist expliciet beheer van bronnen, wat gevaarlijk is: men kan vergeten het geheugen vrij te geven of de geldigheidsduur van pointers te schenden. Een garbage collector is niet altijd een oplossing (hoge resourcekosten, onvoorspelbare pauzes). Fouten in geheugenbeheer leiden tot crashes en kwetsbaarheden.

Oplossing

In Rust worden stack en heap onderscheiden door automatisch beheer: alle waarden worden standaard op de stack geplaatst, terwijl voor dynamisch-groot of langlevende objecten de heap wordt gebruikt via slimme pointers (zoals Box<T>, Vec<T>). Het eigendoms- en uitleensysteem garandeert dat na het overdragen van eigendom of het beëindigen van de levensduur de bronnen automatisch worden vrijgegeven. Dit garandeert veiligheid tijdens de compileertijd en elimineert onnodige pauzes van een garbage collector.

Voorbeeldcode:

fn main() {
    let a = 42;                         // stackallocatie
    let b = Box::new(42);               // heapallocatie
    let mut v = Vec::new();
    v.push(1); v.push(2);               // arraygegevens op de heap
}

Belangrijke kenmerken:

Standaardallocatie van eenvoudige types (Copy) — op de stack.
Dynamische collecties en Box<T> gebruiken de heap, maar worden vrijgegeven via RAII.
Al het geheugen wordt gegarandeerd vrijgegeven zonder handmatige tussenkomst of GC.

Tricky vragen.

Kan men handmatig geheugen op de stack vrijgeven (drop)?

Nee. Het vrijgeven van stack-geallocateerde variabelen gebeurt automatisch wanneer men uit de scope gaat, handmatig een drop doen is nutteloos en zelfs niet toegestaan voor stack pointers.

Verplaatst een move een variabele naar de heap?

Nee. Het verplaatsen van een variabele tussen eigenaren verplaatst deze niet noodzakelijk naar de heap; alleen het eigendom verandert.

Garandeert het gebruik van Box<T> dat T altijd op de heap staat?

Ja, Box<T> alloceert T inderdaad op de heap, maar eigendom en levensduur worden nog steeds strikt gecontroleerd.

Typische fouten en anti-patterns

Verwarring in levensduur van verwijzingen, pogingen om een verwijzing naar een lokaal stack-object vanuit een functie terug te geven.
Gebruik van de heap voor kleine objecten zonder noodzaak (malloc-overhead).
Negeert het eigendom en move-semantiek voor collecties en Box<T>.

Voorbeeld uit het leven

Negatief geval

In het project worden globale vectors (Vec<T>) gebruikt met handmatige opruiming via mem::forget of drop, soms leidend tot dangling pointers naar verwijderd geheugen.

Voordelen:

Veel flexibiliteit en handmatig resourcebeheer.

Nadelen:

Hoge kans op fouten en lekken, vermindering van veiligheid.

Positief geval

Objecten worden expliciet gealloceerd via Box, gegevensoverdracht gebeurt volgens de eigendomsregels, voor collecties worden slimme pointers gebruikt en er worden geen verwijzingen naar stack-variabelen teruggegeven.