Perché Zig non ha allocazioni nascoste

In Zig, nessuna funzione della libreria standard acquisisce silenziosamente memoria dall'heap. Se il codice deve allocare, deve dichiararlo esplicitamente. 📦

Qualsiasi operazione che alloca riceve un allocator come parametro. La memoria non può comparire se non si fornisce a una funzione lo strumento per crearla.

Zig non ha un operatore new né un garbage collector. Nulla accede all'heap alle Sue spalle come avviene in molti linguaggi.

Poiché l'allocazione è visibile, sa sempre da dove proviene la memoria. Questo è fondamentale per i chip embedded, i kernel e i cicli di gioco con vincoli prestazionali.

Una funzione che può allocare lo mostra nella propria firma: riceve un allocator e di solito restituisce una error union con !.

Le variabili locali semplici vivono nello stack e non richiedono un allocator. Ne utilizza uno solo quando un valore deve sopravvivere alla propria funzione o crescere durante l'esecuzione.

Richiedere memoria dall'heap può fallire, quindi le funzioni che allocano restituiscono un errore. Deve gestire un possibile OutOfMemory e non ignorarlo mai.

Chi chiama l'allocator possiede il risultato e deve liberarlo. Zig non libera mai la memoria al posto Suo, quindi la proprietà è sempre chiara.

Poiché l'allocator è un parametro, può scambiare le strategie senza modificare la logica. I test usano un allocator e la produzione un altro.

Una libreria ben scritta non nasconde mai un'allocazione. Accetta il Suo allocator, così può controllare la memoria anche all'interno del codice di altri sviluppatori.

Questa regola fa parte della promessa di Zig di non avere flusso di controllo nascosto. L'allocazione esplicita mantiene i programmi prevedibili e facili da comprendere. ✅

Ha visto che Zig non esegue allocazioni nascoste: la memoria arriva solo tramite un allocator passato alla funzione, e Lei possiede e libera tutto ciò che crea. 🎯