واجهة المخصّص

Every allocator in Zig is handed around as a single type, std.mem.Allocator. Your code talks to that one interface, never a concrete backend.

std.mem.Allocator is a small interface: a pointer plus a table of functions. It describes what an allocator can do, not which one you use.

A page allocator, an arena, or a test allocator all expose the same shape. Swapping one for another needs no change to calling code.

You obtain a concrete allocator, then take its .allocator() handle to pass around as the generic std.mem.Allocator type.

Once you hold an allocator, you pass that one value into any function that needs memory. The whole program can share a single source.

std.heap.page_allocator asks the OS directly for memory. It is simple but coarse, so it suits big or long-lived blocks, not tiny ones.

The GeneralPurposeAllocator is the everyday choice in debug builds. It tracks every block and reports leaks and double-frees for you.

Coding against the interface means your function works with any allocator. The same code runs in tests, on bare metal, or in a server.

A function does not care which allocator it got. It simply calls methods like alloc and free on the std.mem.Allocator it was given.

Zig has no single global heap. You decide which allocator each part of your program uses, keeping memory sources visible and local.

In tests you pass std.testing.allocator instead. Same code, but now leaks fail the test, proving the interface pays off. ✅

Think about what type all Zig allocators share.

You learned that std.mem.Allocator is one interface over many backends, so code that asks for memory works with any allocator you supply. 🎯