Réponse.

Histoire de la question :

En Rust, la gestion des ressources sans ramasse-miettes est rendue possible grâce à des règles strictes de propriété et de cycle de vie des objets. Pour automatiser la libération des ressources (par exemple, des descripteurs de fichiers, des sockets, de la mémoire provenant de bibliothèques tierces), le trait Drop a été introduit dès le début du développement du langage. C'est le principal moyen de "réaction" à la fin de la vie d'un objet, qui est utilisé pour finaliser et retourner des ressources au système d'exploitation ou pour libérer de la mémoire.

Problème :

Les types ordinaires de Rust nettoient automatiquement leurs propres ressources, mais lorsqu'une structure détient une ressource nécessitant une libération manuelle (par exemple, un fichier ouvert ou un pointeur non sécurisé), le désir ou l'oubli du développeur peuvent entraîner des fuites ou des courses de ressources. Si Drop est mal implémenté (par exemple, que la possibilité de double libération de mémoire n'a pas été prise en compte), cela peut entraîner des erreurs d'exécution.

Solution :

Le trait Drop permet de définir une méthode spéciale drop(&mut self), qui est appelée automatiquement lors de la destruction de la valeur. Elle est appropriée pour libérer des ressources exactement lorsque l'objet sort du champ de vision. Il est important de se rappeler que la ressource (par exemple, fermer un fichier) ne doit être libérée qu'ici.

Exemple de code :

struct RawFile {
    handle: *mut libc::FILE,
}

impl Drop for RawFile {
    fn drop(&mut self) {
        if !self.handle.is_null() {
            unsafe {
                libc::fclose(self.handle);
            }
        }
    }
}

Caractéristiques clés :

La méthode drop n'est pas appelée explicitement — seulement par le compilateur.
Drop est implémenté uniquement pour les structures qui possèdent des ressources non-Rust.
Drop ne s'exécute pas lors d'une fuite via mem::forget ou panic! par défaut (en dehors de unwinding).

Questions pièges.

Peut-on appeler drop explicitement pour un objet afin de libérer la ressource plus tôt ?

Non, appeler directement la méthode drop (&obj.drop()) est interdit — uniquement via la fonction std::mem::drop(obj), qui prend la possession de l'objet et appelle drop automatiquement. L'appel direct de drop() ne se compile pas.

Exemple de code :

fn main() {
    let f = File::open("foo.txt").unwrap();
    // drop(&mut f); // Erreur de compilation !
    std::mem::drop(f); // Correct : fermeture du fichier
}

Que se passera-t-il si une structure avec Drop est soumise à memcpy ou move ? Le destructeur ne sera-t-il pas appelé deux fois ?

Non, le destructeur est toujours appelé exactement une fois au cours du cycle de vie de l'objet, et le compilateur veille à cela. Mais si on fait une copie unsafe de "raw" bytes de la structure ou utilise mem::forget, drop peut ne pas être appelé du tout — d'où le danger.

Peut-on implémenter Drop et Copy en même temps pour le même type ?

Non, le compilateur interdit cette combinaison : un type qui implémente Drop ne peut pas être Copy, afin de garantir un appel unique au destructeur et d'exclure une double libération de ressources.

Erreurs typiques et anti-patterns

Appel direct de la méthode drop (interdit)
Ressource non libérée ou fichier non fermé à cause de l'oubli de Drop
Utilisation après libération (use after free) via un pointeur imprudent
Mise en œuvre de Drop en même temps que Copy (Erreur de compilation)
Chaînes de propriété complexes, où l'ordre de drop est critique

Exemple de la vie réelle

Cas négatif

Un programmeur a écrit un simple wrapper pour travailler avec un fichier ouvert, mais a oublié d'implémenter Drop et de fermer le descripteur lors de la suppression de l'objet.

Avantages :

Pas de code superflu, structure simple à comprendre

Inconvénients :

Après que le fichier soit sorti de la portée, le descripteur reste ouvert
Peut entraîner une saturation des descripteurs et échouer le système d'exploitation

Cas positif

Un développeur a implémenté Drop pour le wrapper de descripteur de fichiers, fermant explicitement le fichier dans drop. Maintenant, lors de la sortie de n'importe quelle variable de cette structure de la fonction ou panic, la ressource est libérée de manière garantie.