Quiz : Gestion essentielle de la mémoire en Rust

Le code ne compile pas parce que la propriété de wisdom a été déplacée vers take_knowledge et ne peut donc plus être utilisée ensuite.

Voici trois façons de résoudre ce problème :

1. Passer par référence (emprunter la valeur) :

fn borrow_it(text: &String) {
    println!("Inside: {}", text);
}
borrow_it(&wisdom);  // Now wisdom can be used after

2. Cloner la valeur (créer une nouvelle copie) :

take_knowledge(wisdom.clone());  // Original wisdom remains valid

3. Retourner la propriété depuis la fonction :

fn take_and_return(text: String) -> String {
    println!("Inside: {}", text);
    text  // Return ownership back
}
let wisdom = take_and_return(wisdom);  // Reassign returned ownership

Chaque approche a des cas d’utilisation différents :

• Références : les plus efficaces, mais nécessitent une gestion des durées de vie
• Clonage : simple mais potentiellement coûteux
• Retour de propriété : utile pour transformer des valeurs

Bonne pratique : utilisez les références sauf si vous avez besoin d’un transfert de propriété.

Ce code compile avec succès grâce aux règles d’élision des durées de vie de Rust. Ces règles permettent au compilateur d’inférer automatiquement les durées de vie dans les motifs courants.

Les trois règles d’élision sont :

1. Chaque paramètre reçoit son propre paramètre de durée de vie
2. S’il n’y a qu’un seul paramètre d’entrée, cette durée de vie est attribuée à tous les paramètres de sortie
3. S’il y a plusieurs paramètres d’entrée, mais que l’un d’eux est &self ou &mut self, la durée de vie de self est attribuée à tous les paramètres de sortie

Cette fonction est équivalente à :

fn first_word<'a>(s: &'a str) -> &'a str {
    // ... same implementation
}

Motifs courants où l’élision fonctionne :

// These don't need explicit lifetimes
fn get_str(s: &str) -> &str { s }
fn get_first(s: &str) -> &str { &s[0..1] }

// These would need explicit lifetimes
fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() { x } else { y }
}

Bonne pratique : laissez l’élision faire son travail quand c’est possible, mais comprenez quand des durées de vie explicites sont nécessaires.

Ce code échoue parce que le compilateur ne peut pas déterminer la taille de CatList à la compilation. La nature récursive du type signifie qu’il pourrait être infiniment grand !

Voici comment le corriger en utilisant Box<T> :

#[derive(Debug)]
enum CatList {
    Cons(i32, Box<CatList>),  // Box provides a fixed-size pointer
    Nil,
}

fn main() {
    let catlist = CatList::Cons(1,
        Box::new(CatList::Cons(2,
            Box::new(CatList::Cons(3,
                Box::new(CatList::Nil))))));
}

Pourquoi Box<T> fonctionne :

1. Box fournit un pointeur de taille fixe (généralement 8 octets sur les systèmes 64 bits)
2. Les données réelles sont stockées sur le tas
3. Le compilateur sait maintenant exactement quel espace allouer

Cas d’utilisation courants de Box<T> :

• Structures de données récursives (listes chaînées, arbres)
• Grandes données que vous voulez garantir d’être allouées sur le tas
• Objets de trait lorsque vous avez besoin d’un dispatch dynamique

Meilleure pratique : utilisez Box<T> lorsque vous avez besoin de :

• Types récursifs
• Garantir l’allocation sur le tas
• Déplacer de grandes données sans les copier

Décomposons le fonctionnement de Rc :

1. Création initiale avec Rc::new(): compteur = 1
2. Premier clone pour marcus: compteur = 2
3. Second clone pour aurelius: compteur = 3

Caractéristiques importantes de Rc :

use std::rc::Rc;

fn demonstrate_rc() {
    let original = Rc::new(String::from("Shared"));
    println!("Count after creation: {}", Rc::strong_count(&original)); // 1

    {
        let copy = Rc::clone(&original);
        println!("Count inside scope: {}", Rc::strong_count(&original)); // 2
    } // copy is dropped here

    println!("Count after scope: {}", Rc::strong_count(&original)); // 1
}

Points clés :

• Rc::clone() est peu coûteux – il ne fait qu’incrémenter un compteur
• Rc n’est destiné qu’aux scénarios mono‑thread
• Lorsque la dernière référence est libérée, les données sont nettoyées
• Utilisez les références Weak pour éviter les cycles de références

Bonnes pratiques :

• Utilisez Rc quand vous avez besoin d’une propriété partagée
• Envisagez Arc pour les scénarios thread‑safe
• Évitez de créer des cycles de références

Le code échoue parce que les structs contenant des références doivent spécifier des durées de vie. Voici comment le corriger :

// Single lifetime parameter
struct Philosopher<'a> {
    name: &'a str,
    quote: &'a str,
}

// Or different lifetimes if needed
struct PhilosopherFlex<'n, 'q> {
    name: &'n str,
    quote: &'q str,
}

Modèles courants :

// Own the data instead
struct PhilosopherOwned {
    name: String,
    quote: String,
}

// Mixed ownership
struct PhilosopherMixed<'a> {
    name: String,      // Owned
    quote: &'a str,    // Borrowed
}

Bonnes pratiques:

1. Utilisez des types possédés (String) lorsque vous devez stocker des données indéfiniment
2. Utilisez des références lorsque la durée de vie du struct est clairement plus courte que les données
3. Envisagez plusieurs paramètres de durée de vie lorsque les références peuvent avoir des durées différentes
4. Documentez les relations de durée de vie dans les structures complexes

Libérez l’emprunt mutable avant de créer des emprunts partagés. Sinon, cet exemple provoque une panique à l’exécution.

use std::cell::RefCell;
fn main() {
    let data = RefCell::new(42);
    let mut second = data.borrow_mut();
    *second += 1;
    drop(second);
    let read1 = data.borrow();
    let read2 = data.borrow();
    println!("{} {}", *read1, *read2);
}

Cell et RefCell servent des objectifs différents pour la mutabilité intérieure :

use std::cell::{Cell, RefCell};

// Cell for Copy types
struct Counter {
    count: Cell<i32>,
}

impl Counter {
    fn increment(&self) {
        self.count.set(self.count.get() + 1);
    }
}

// RefCell for non-Copy types
struct Logger {
    messages: RefCell<Vec<String>>,
}

impl Logger {
    fn log(&self, msg: &str) {
        self.messages.borrow_mut().push(msg.to_string());
    }
}

Différences clés :

1. Cell :

• Fonctionne au mieux avec les types Copy
• Pas d’API d’emprunt
• Copie ou déplace toujours les valeurs

2. RefCell :

• Fonctionne avec n’importe quel type
• Possède une API d’emprunt
• Vérification d’emprunt à l’exécution

Bonnes pratiques :

1. Utilisez Cell pour les types Copy simples (nombres, bool, etc.)
2. Utilisez RefCell quand vous devez emprunter le contenu
3. Gardez les mutations via Cell/RefCell au minimum
4. Documentez pourquoi la mutabilité intérieure est nécessaire

Verrouiller deux fois le même mutex dans un thread sans libérer le premier garde de verrouillage ne revient jamais normalement. L’API autorise un interblocage ou une panique ; libérez le garde avant de verrouiller à nouveau.

use std::sync::Mutex;
fn main() {
    let lock = Mutex::new(42);
    { let mut guard = lock.lock().unwrap(); *guard += 1; }
    let guard = lock.lock().unwrap();
    println!("{}", *guard);
}

Les références faibles n’empêchent pas la désallocation de leurs cibles. Voici un exemple détaillé :

use std::rc::{Rc, Weak};
use std::cell::RefCell;

// Parent-child tree structure avoiding reference cycles
struct Node {
    next: Option<Rc<Node>>,
    parent: RefCell<Weak<Node>>,  // Weak to prevent cycles
    value: i32,
}

impl Node {
    fn new(value: i32) -> Rc<Node> {
        Rc::new(Node {
            next: None,
            parent: RefCell::new(Weak::new()),
            value,
        })
    }

    fn set_parent(&self, parent: &Rc<Node>) {
        *self.parent.borrow_mut() = Rc::downgrade(parent);
    }

    fn get_parent(&self) -> Option<Rc<Node>> {
        self.parent.borrow().upgrade()
    }
}

Cas d’utilisation courants :

1. Structures de type cache où les entrées peuvent être purgées
2. Structures arborescentes avec références parentales
3. Patrons d’observateur où les sujets peuvent être supprimés
4. Rompre les cycles de références dans des structures de données complexes

Bonnes pratiques :

1. Utiliser les références faibles pour les relations optionnelles
2. Vérifier les résultats de upgrade() avant de les utiliser
3. Documenter clairement les relations de propriété
4. Envisager des alternatives comme des indices pour les cas plus simples

RAII en Rust garantit que les ressources sont correctement gérées. Dans cet exemple, FileWrapper n’a pas besoin d’une implémentation personnalisée de Drop pour que le descripteur de fichier se ferme : son champ File est libéré automatiquement lorsque l’enveloppe sort de la portée.

Vous n’implémentez Drop que lorsque l’enveloppe elle‑même nécessite un nettoyage supplémentaire au‑delà de la libération de ses champs :

use std::fs::File;
use std::io::{self, Write};

struct FileWrapper {
    file: File,
    path: String,
}

impl FileWrapper {
    fn new(path: &str) -> io::Result<FileWrapper> {
        Ok(FileWrapper {
            file: File::create(path)?,
            path: path.to_string(),
        })
    }

    fn write(&mut self, content: &str) -> io::Result<()> {
        self.file.write_all(content.as_bytes())
    }
}

impl Drop for FileWrapper {
    fn drop(&mut self) {
        // Ensure file is properly closed
        // Could also do cleanup like deletion
        println!("Closing file: {}", self.path);
    }
}

Patrons RAII :

1. Le constructeur acquiert les ressources
2. Les méthodes utilisent les ressources en toute sécurité
3. Les champs sont libérés automatiquement lorsque le propriétaire sort de la portée
4. Un Drop personnalisé ajoute un nettoyage supplémentaire si besoin
5. Utilisez ? pour la propagation d’erreurs

Bonnes pratiques :

1. S’appuyer sur les implémentations Drop de la bibliothèque standard lorsqu’elles modélisent déjà la ressource
2. Garder la gestion des ressources simple et évidente
3. Utiliser les types de la bibliothèque standard quand c’est possible
4. Documenter le comportement de nettoyage
5. Envisager d’utiliser des motifs de garde pour les opérations à portée limitée

Copy effectue une copie implicite bit à bit. Clone est explicite et peut allouer de la mémoire ; ici les deux champs String reçoivent des copies indépendantes. La pile ou le tas ne détermine pas si un type implémente Copy.

Décomposons la disposition mémoire de la struct et son optimisation :

// Typical current 64-bit Rust layout: 32 bytes
struct Metadata {
    id: u32,       // 4 bytes
    name: String,  // 24 bytes on 64-bit systems
    active: bool   // 1 byte + padding/alignment
}

// Reordering fields may reduce padding for repr(C) structs,
// but default Rust layout is not a stable ABI guarantee.
struct OptimizedMetadata {
    name: String,   // 24 bytes
    id: u32,       // 4 bytes
    active: bool    // 1 byte + 3 padding
}

// Further optimization with packing
#[repr(packed)]
struct PackedMetadata {
    id: u32,
    active: bool,
    name: String,
}

Considérations de disposition mémoire :

1. Exigences d’alignement :

• u32 : alignement de 4 octets
• String : alignement de 8 octets et taille de 24 octets sur les cibles 64 bits courantes
• bool : alignement de 1 octet

2. Stratégies d’ordre des champs :

• Regrouper les champs de taille similaire
• Placer les alignements les plus grands en premier
• Envisager l’optimisation des lignes de cache

Bonnes pratiques :

1. Pour le FFI ou des hypothèses de mise en page stable, utilisez un repr(...) approprié
2. Utilisez des tailles d’entiers appropriées
3. Envisagez d’utiliser Option pour les champs optionnels
4. Mesurez les structs critiques en taille avec std::mem::size_of
5. Utilisez #[repr(packed)] avec prudence – cela peut affecter les performances