Quiz : Gestion essentielle de la mémoire en Rust

Ce code ne compile pas à cause des règles de propriété de Rust. Lorsque nous assignons philosopher à greeting, la propriété du String est déplacée vers greeting. Après ce déplacement, philosopher n’est plus valide.

Voici trois façons de corriger cela :

1. Cloner la chaîne (crée une nouvelle copie) :

let greeting = philosopher.clone();

2. Utiliser une référence (emprunte la valeur) :

let greeting = &philosopher;

3. Utiliser une tranche de chaîne (emprunte une partie de la chaîne) :

let greeting = &philosopher[..];

Chaque solution a des cas d’utilisation et des implications de performance différents. Le clonage est plus coûteux mais vous donne la propriété, tandis que les références sont moins chères mais soumises à des contraintes de durée de vie.

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 viole les règles fondamentales d’emprunt de Rust :

• Une SEULE référence mutable à une valeur à la fois
• OU n’importe quel nombre de références immuables
• Les références ne peuvent pas survivre à leur référent

Voici comment corriger le code :

1. Utiliser un scoping séquentiel :

let mut wisdom = String::from("He who laughs at");
{
    let ref1 = &mut wisdom;
    ref1.push_str(" himself never runs");
}  // ref1 goes out of scope
let ref2 = &mut wisdom;  // Now this is valid
ref2.push_str(" out of things to laugh at.");

2. Ou modifier la chaîne dans un emprunt unique :

let mut wisdom = String::from("He who laughs at");
let ref1 = &mut wisdom;
ref1.push_str(" himself never runs out of things to laugh at.");

Ces règles empêchent les courses de données à la compilation, rendant Rust sûr pour le multithreading par défaut.

Piège fréquent : essayer d’utiliser plusieurs références mutables pour éviter le clonage ou pour modifier différentes parties de la même valeur simultanément.

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

La référence renvoyée doit rester dans une durée de vie valide pour les deux entrées. Elle ne peut survivre à aucune des valeurs empruntées. Les annotations décrivent cette relation sans prolonger les durées de vie.

fn longest<'a>(a: &'a str, b: &'a str) -> &'a str {
    if a.len() > b.len() { a } else { b }
}

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

Rc (Comptage de références) est conçu pour les scénarios monothread où vous avez besoin d’une propriété partagée.

Cas d’utilisation courants :

use std::rc::Rc;
use std::cell::RefCell;

// Shared ownership in data structures
struct Node {
    next: Option<Rc<Node>>,
    value: i32,
}

// Combining with interior mutability
struct SharedState {
    data: Rc<RefCell<Vec<String>>>,
}

// Multiple owners of same data
let original = Rc::new(vec![1, 2, 3]);
let clone1 = Rc::clone(&original);
let clone2 = Rc::clone(&original);

Points clés:

1. Utilisez Rc lorsque :

• Plusieurs parties de votre code ont besoin de posséder la donnée
• Vous savez que le partage est monothread
• La durée de vie ne peut pas être déterminée statiquement

2. Utilisez Arc à la place lorsque :

• Vous avez besoin d’un partage sûr pour les threads
• Plusieurs threads ont besoin de posséder la donnée

3. Limitations de Rc :

• Pas sûr pour les threads
• Légère surcharge à l’exécution
• Ne peut pas rompre automatiquement les cycles de références

Bonnes pratiques :

1. Privilégiez la propriété unique quand c’est possible
2. Utilisez Rc pour un partage monothread
3. Utilisez Arc pour les scénarios multithread
4. Combinez avec Weak pour éviter les cycles de références

RefCell<T> vérifie les emprunts à l’exécution et n’est pas Sync : ne partagez pas une référence entre threads. Il peut être déplacé vers un autre thread si T: Send. RwLock<T> fournit un accès synchronisé, sous réserve de ses contraintes de types.

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

Les abstractions à coût nul permettent un code optimisé efficace, sans garantir des temps identiques pour chaque compilateur ou niveau d’optimisation. Les deux fonctions calculent la même somme. Mesurez la charge réelle si les performances sont importantes.

use std::ops::Range;
trait ZeroCost {
    fn process(&self) -> u32;
}
impl ZeroCost for Range<u32> {
    fn process(&self) -> u32 {
        self.clone().fold(0, |acc, x| acc + x)
    }
}