{"@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","name":"En Rust, où sont stockées les variables locales de type primitif comme i32 ou bool ?","acceptedAnswer":{"@type":"Answer","text":"Les variables locales de type primitif sont stockées sur la stack (pile). La stack offre une allocation et désallocation très rapide car elle fonctionne selon le principe LIFO (Last In, First Out). Les types primitifs ont une taille connue à la compilation, ce qui permet au compilateur de réserver l'espace nécessaire sur la stack frame de la fonction courante."}},{"@type":"Question","name":"Quel smart pointer utiliser pour allouer une valeur sur le heap avec un unique propriétaire ?","acceptedAnswer":{"@type":"Answer","text":"Box est le smart pointer le plus simple pour allouer des données sur le heap. Il garantit un unique propriétaire et libère automatiquement la mémoire lorsque le Box sort du scope. Box est utile pour les types de taille inconnue à la compilation, pour les grandes structures qu'on ne veut pas copier sur la stack, ou pour les types récursifs."}},{"@type":"Question","name":"Qu'est-ce que le pattern RAII (Resource Acquisition Is Initialization) en Rust ?","acceptedAnswer":{"@type":"Answer","text":"RAII est un pattern où les ressources (mémoire, fichiers, connexions) sont acquises lors de la création d'un objet et libérées automatiquement lors de sa destruction. En Rust, cela se fait via le trait Drop qui est appelé automatiquement quand une valeur sort du scope. Ce pattern garantit qu'aucune ressource n'est oubliée et évite les fuites mémoire."}},{"@type":"Question","name":"Quand le trait Drop est-il automatiquement appelé en Rust ?","acceptedAnswer":{"@type":"Answer","text":"Le trait Drop est appelé automatiquement quand une valeur sort du scope (fin de bloc, fin de fonction, réassignation). L'ordre de destruction suit l'ordre inverse de déclaration (LIFO). Le compilateur insère automatiquement les appels à drop(), il n'est jamais nécessaire de l'appeler manuellement. Pour forcer une destruction anticipée, utiliser std::mem::drop()."}},{"@type":"Question","name":"Comment créer une fuite mémoire (memory leak) avec Rc en Rust ?","acceptedAnswer":{"@type":"Answer","text":"Une fuite mémoire peut se produire avec Rc en créant des cycles de références. Si A contient un Rc vers B et B contient un Rc vers A, le compteur de références ne descendra jamais à zéro même si aucune variable externe ne référence plus le cycle. Pour éviter cela, utiliser Weak pour briser le cycle en créant une référence non-propriétaire."}},{"@type":"Question","name":"Quel est le rôle de Weak dans la gestion des cycles de références ?","acceptedAnswer":{"@type":"Answer","text":"Weak crée une référence non-propriétaire vers une valeur gérée par Rc ou Arc. Contrairement à Rc, Weak n'incrémente pas le strong count et ne prévient pas la destruction de la valeur. Pour accéder à la valeur, il faut appeler upgrade() qui retourne Option>. Cela permet de briser les cycles tout en gardant une référence observable."}},{"@type":"Question","name":"Qu'est-ce que Pin garantit en Rust ?","acceptedAnswer":{"@type":"Answer","text":"Pin garantit qu'une valeur ne sera pas déplacée en mémoire une fois pinnée. C'est crucial pour les types auto-référentiels (qui contiennent des pointeurs vers eux-mêmes), comme les Futures générées par async/await. Sans Pin, un déplacement invaliderait ces pointeurs internes. Pin ne garantit pas l'immutabilité, seulement l'absence de déplacement."}},{"@type":"Question","name":"Quelle est la différence principale entre l'allocateur global et un allocateur custom en Rust ?","acceptedAnswer":{"@type":"Answer","text":"L'allocateur global (par défaut jemalloc ou system) est utilisé pour toutes les allocations heap du programme. Un allocateur custom permet d'optimiser pour des cas spécifiques : arena allocators pour allocations groupées, bump allocators pour allocations séquentielles rapides, ou allocateurs avec tracking pour le debugging. Depuis Rust 1.28, on peut définir un allocateur global via #[global_allocator]."}},{"@type":"Question","name":"Que fait std::mem::drop() et quand est-il utile ?","acceptedAnswer":{"@type":"Answer","text":"std::mem::drop() prend possession d'une valeur et la détruit immédiatement, appelant son implémentation de Drop si elle en a une. C'est utile pour libérer des ressources avant la fin naturelle du scope, par exemple libérer un lock Mutex avant la fin d'une fonction, ou libérer une connexion dès qu'elle n'est plus nécessaire pour optimiser l'utilisation des ressources."}},{"@type":"Question","name":"Que fait std::mem::forget() et quel risque présente son utilisation ?","acceptedAnswer":{"@type":"Answer","text":"std::mem::forget() prend possession d'une valeur et l'oublie sans appeler son destructeur Drop. La mémoire n'est jamais libérée, causant potentiellement une fuite. C'est parfois nécessaire en unsafe Rust ou FFI pour transférer la propriété à du code externe. Utiliser forget n'est pas unsafe, mais peut causer des fuites de ressources si mal utilisé."}},{"@type":"Question","name":"Comment fonctionne l'alignement mémoire (memory alignment) en Rust ?","acceptedAnswer":{"@type":"Answer","text":"Chaque type en Rust a un alignement qui détermine les adresses mémoire valides pour le stocker. L'alignement est généralement la taille du plus grand champ primitif. Le compilateur peut ajouter du padding entre les champs d'une struct pour respecter l'alignement. #[repr(C)] force un layout compatible C, tandis que #[repr(packed)] supprime le padding mais peut dégrader les performances."}},{"@type":"Question","name":"Quel problème résout le trait Unpin en relation avec Pin ?","acceptedAnswer":{"@type":"Answer","text":"Unpin est un marker trait auto-implémenté pour les types qui peuvent être déplacés même quand pinnés. La plupart des types sont Unpin par défaut. Les types !Unpin (comme les Futures générées par async) ne peuvent pas être déplacés après avoir été pinnés. Cela permet à Pin d'être un no-op pour les types standards tout en protégeant les types auto-référentiels."}},{"@type":"Question","name":"Comment créer un Pin> pour une valeur qui doit être pinnée sur le heap ?","acceptedAnswer":{"@type":"Answer","text":"Pour pinner une valeur sur le heap, utiliser Box::pin(value) qui retourne directement un Pin>. Cela garantit que la valeur ne sera jamais déplacée car elle est allouée sur le heap et le Pin empêche d'obtenir une référence mutable qui permettrait un std::mem::swap(). C'est la méthode standard pour les Futures et types auto-référentiels."}},{"@type":"Question","name":"Quelle est la différence entre std::mem::size_of::() et std::mem::size_of_val(&v) ?","acceptedAnswer":{"@type":"Answer","text":"size_of::() retourne la taille en bytes d'un type connu à la compilation (statique). size_of_val(&v) retourne la taille d'une valeur particulière, utile pour les types dynamiquement sized (DST) comme les slices ou trait objects. Pour un slice, size_of_val retourne la taille totale des éléments, pas la taille du fat pointer."}},{"@type":"Question","name":"Pourquoi est-il impossible d'implémenter Drop et Copy pour le même type ?","acceptedAnswer":{"@type":"Answer","text":"Copy indique qu'un type peut être dupliqué par simple copie de bits (memcpy), sans logique spéciale. Drop indique qu'un type a besoin d'une logique de nettoyage à la destruction. Si un type était Copy avec Drop, chaque copie aurait sa propre destruction, causant des double-free ou autres problèmes. C'est une invariant fondamental du système de types Rust."}},{"@type":"Question","name":"Qu'est-ce qu'un arena allocator et quand l'utiliser en Rust ?","acceptedAnswer":{"@type":"Answer","text":"Un arena allocator alloue des objets dans une grande zone mémoire pré-allouée et les libère tous en une seule opération. C'est très efficace pour les allocations temporaires dans une phase de calcul (parsing, compilation). Les crates comme bumpalo ou typed-arena fournissent des implémentations. Idéal quand de nombreuses petites allocations ont la même durée de vie."}},{"@type":"Question","name":"Comment ManuallyDrop permet-il de contrôler manuellement la destruction ?","acceptedAnswer":{"@type":"Answer","text":"ManuallyDrop est un wrapper qui empêche l'appel automatique du destructeur Drop. La valeur reste valide mais ne sera pas automatiquement détruite à la sortie du scope. Pour la détruire, utiliser ManuallyDrop::drop(&mut val) qui est unsafe. Utile en unsafe Rust pour contrôler précisément quand et si une valeur est détruite, notamment en FFI."}},{"@type":"Question","name":"Quelle est la taille mémoire d'un Vec vide sur la stack (sans compter le buffer heap) ?","acceptedAnswer":{"@type":"Answer","text":"Un Vec sur la stack contient trois pointeurs-taille: un pointeur vers le buffer heap, la longueur actuelle (len), et la capacité (capacity). Sur une architecture 64-bit, cela fait 3 x 8 = 24 bytes. Un Vec vide a un pointeur dangling (mais valide et aligné), len=0 et capacity=0, donc aucune allocation heap n'est faite."}},{"@type":"Question","name":"Comment fonctionne le niche-filling optimization pour Option> ?","acceptedAnswer":{"@type":"Answer","text":"Le niche-filling utilise des valeurs invalides d'un type pour représenter None sans overhead mémoire. NonNull garantit que le pointeur n'est jamais null, donc null peut représenter None. Ainsi Option> a la même taille que NonNull. Cette optimisation s'applique aussi à Box, Rc, Arc, références, et enums avec discriminant inutilisé."}},{"@type":"Question","name":"Quel est l'impact de #[repr(C)] sur le layout mémoire d'une struct ?","acceptedAnswer":{"@type":"Answer","text":"#[repr(C)] force un layout mémoire compatible avec C : les champs sont ordonnés exactement comme déclarés, avec le padding minimal requis pour l'alignement. Sans cet attribut, Rust peut réordonner les champs pour optimiser la taille. #[repr(C)] est essentiel pour FFI avec du code C, pour des structures partagées en mémoire, ou pour garantir un layout déterministe."}}]}