Pourquoi Zig n'a pas d'allocations cachées

Dans Zig, aucune fonction de la bibliothèque standard ne s’empare discrètement de mémoire du tas. Si le code doit allouer, il doit le dire explicitement. 📦

Tout ce qui alloue prend un allocator en paramètre. La mémoire ne peut pas apparaître si vous ne fournissez pas à une fonction l’outil nécessaire pour la créer.

Zig ne possède ni opérateur new ni ramasse-miettes. Rien n’accède au tas dans votre dos comme le font de nombreux langages.

Comme l’allocation est visible, vous savez toujours d’où vient la mémoire. C’est essentiel pour les puces embarquées, les noyaux et les boucles de jeu exigeantes.

Une fonction susceptible d’allouer l’indique dans sa signature : elle prend un allocator et renvoie généralement une union d’erreurs avec !.

Les variables locales ordinaires vivent sur la pile et n’ont besoin d’aucun allocator. Vous n’en utilisez un que lorsqu’une valeur doit survivre à sa fonction ou grandir pendant l’exécution.

Demander de la mémoire sur le tas peut échouer, c’est pourquoi les fonctions d’allocation renvoient une erreur. Vous devez gérer un éventuel OutOfMemory et ne jamais l’ignorer.

Quiconque appelle l’allocator est propriétaire du résultat et doit le libérer. Zig ne libère jamais votre mémoire à votre place : la propriété est donc toujours claire.

Comme l’allocator est un paramètre, vous pouvez changer de stratégie sans modifier la logique. Les tests utilisent un allocator, la production un autre.

Une bibliothèque bien écrite ne dissimule jamais une allocation. Elle accepte votre allocator, ce qui vous permet de contrôler la mémoire, même dans le code d’autrui.

Cette règle fait partie de la promesse de Zig : aucun flux de contrôle caché. Une allocation explicite rend les programmes prévisibles et faciles à comprendre. ✅

Vous avez vu que Zig n’effectue aucune allocation cachée : la mémoire provient uniquement d’un allocator que vous transmettez, et vous êtes propriétaire de tout ce que vous créez et libérez. 🎯