C++.CodeCompared.To/Zig

Writing to stdout is I/O, I/O can fail, so main returns an error union (!void) and the write is prefixed with try. The I/O implementation arrives as a parameter rather than being reached for globally, because Zig objects to hidden global state as much as to hidden control flow. And no newline is added for you. Compare std::cout << …, which can throw if exceptions are enabled on the stream, allocates in ways you do not see, and is flushed by std::endl — three behaviors the Zig line makes visible or does without.

std::format returns a std::string, which means a heap allocation on every call that you did not ask for and cannot decline. std::fmt.bufPrint writes into a buffer you supplied and returns a slice of it, so the allocation is a stack array you can see — and if the output does not fit you get error.NoSpaceLeft rather than a silent growth. Note the specifiers are typed: {s} for a string and {d} for an integer, because Zig will not guess. When you do want an allocating version it is std.fmt.allocPrint, and it takes an allocator as its first argument.

Because build.zig is Zig, there is no second syntax, no second type system and no second set of editor tooling — a build step is a function call and a conditional is an if. The more remarkable half is cross-compilation: Zig ships the C headers and libc source for every target it supports, so -Dtarget=aarch64-linux-musl works from any host with nothing else installed. That capability is why people who never write Zig still install it, which is the subject of the C-interop section below.

In C++ the answer is no — push_back may allocate, may move every element, runs constructors and destructors, and may throw, and none of that is visible at the call site. In Zig every one of those is spelled: memory comes from an allocator parameter, the failure path is marked try, cleanup is a defer you wrote, and there are no implicit constructor or destructor calls at all. The price is on the screen — the Zig column is longer and you can never stop thinking about allocation. Whether that is discipline or tedium is the question the rest of this page is really about.

A C++ destructor belongs to the type, so its author guarantees cleanup for every user; a defer belongs to the block, so every caller must write it and the compiler will not remind them. What Zig adds is errdefer, which runs only when the function returns an error — exactly the "undo what I have done so far" half of a constructor's exception safety, expressed directly instead of emerging from destructor ordering. Deferred statements run last-registered-first at scope exit, and unlike Go's they are scoped to the block, not the function.

The stricter rule is that an unused local is a compile error, as is an unused const and a mutable var that is never mutated — the compiler will tell you to write const instead. This is genuinely irritating while debugging, when commenting out one line orphans a variable, and the escape hatch is _ = variable;. The reasoning matches Go's: a warning nobody must fix accumulates until nobody reads any of them.

There are no implicit numeric conversions, and each conversion has its own builtin naming exactly what it does: @intCast between integer types, @floatFromInt and @intFromFloat across the divide, @truncate when you genuinely want the low bits, @bitCast to reinterpret. The safety difference is the important one: @intCast asserts the value fits and traps in a safe build if it does not, where C++'s implicit narrowing silently gives you 44. When truncation is what you want, @truncate says so.

Zig has no undefined overflow. Plain + is checked and traps in Debug and ReleaseSafe, which turns a silent miscompilation into a crash at the exact line. The wrapping operators are separate — +%, -%, *% — so wrapping is something you opt into visibly rather than something unsigned types do behind you, and +| saturates. @addWithOverflow returns both the result and a flag when you want to ask. Note this is a runtime check with a real cost: in ReleaseFast it is removed, and overflow there is undefined.

A C++ template is a separate, pattern-matching, compile-time language layered on top of the runtime one, with its own rules for everything. In Zig, type is just a type, so a generic function is a normal function with a parameter marked comptime — the syntax in the body is the same syntax you write everywhere, and the same code can often run at compile time or runtime unchanged. The body is checked when instantiated, exactly as a template body is, so errors arrive at the call rather than the definition. That is the trade against Rust and Go, whose bounds are declared and checked once.

Nothing here is template machinery: Stack(i32, 8) is a function call evaluated at compile time whose result happens to be a type, and @This() refers to the enclosing struct so methods can name their own type. Non-type parameters like capacity need no special syntax because every comptime parameter is already a value. This is how the whole standard library is written — std.ArrayList(T) is that function — and it is also why Zig has no separate concept of specialization: an if inside the function returning a different struct is specialization.

comptime subsumes all of them. There is no preprocessor, so no #define, no #include and no #ifdef — conditional compilation is an ordinary if on a comptime value, and the dead branch is simply not analyzed. There is no constexpr keyword on functions because any function may run at compile time if its inputs are known. @compileError replaces static_assert and produces a message you wrote rather than a template instantiation backtrace. The constraint that makes this safe: comptime code cannot do I/O or call into the host, so a build stays deterministic.

@typeInfo hands back an ordinary comptime value describing the type, so enumerating fields is a loop rather than a metaprogramming technique — and inline for unrolls it at compile time so field.name is a compile-time constant in each iteration. This is what makes Zig's JSON encoder, formatter and hashing work on any struct with no macros, no code generation and no boilerplate on the type. C++26's P2996 will bring genuine reflection; until then std::is_trivially_copyable_v and its siblings answer questions but cannot enumerate anything.

The consequence is a property C++ cannot state: a function's signature tells you whether it can allocate. That makes arena allocation, fixed-buffer allocation and embedded targets ordinary rather than heroic — swap std.heap.FixedBufferAllocator in and the same code allocates from a stack array. DebugAllocator is worth knowing: it detects leaks, double frees and use-after-free, and reports them at deinit, so a leak is a test failure rather than something you go looking for with Valgrind. The cost is that the allocator becomes a parameter threaded through your entire API.

Zig has no unique_ptr, no shared_ptr, no move semantics and no ownership in the type system. A pointer is a pointer; who frees it is a convention carried in documentation and in the defer you remember. Forgetting one is a leak, and freeing twice is undefined behavior the way it is in C. What Zig offers instead is detection rather than prevention: DebugAllocator catches leaks, double frees and use-after-free at runtime, and the safe build modes trap on them. Against Rust, which proves these statically, this is a clear step back; against C, where nothing is checked at all, a clear step forward.

An error union PortError!i32 holds either an i32 or one of the named errors, and an error set is inferred automatically when you write !i32 — so the compiler knows the exhaustive list of what a function can return and will tell you if a switch over it misses a case. try propagates, catch handles, and both are visible at the call site, so there are no invisible early exits. Errors are just values with no payload and no allocation, which is why this costs nothing and works on a microcontroller. The tradeoff against exceptions is the same one Go makes, with better type checking.

The C++ rule — if a constructor throws, the destructor does not run, but fully-constructed members are destroyed — is correct, non-obvious, and the reason RAII members rather than raw pointers are mandatory. Zig has no constructors and no such rule: you write errdefer after each acquisition, and the failure path unwinds in reverse. It is more typing and there is nothing subtle left to know. The pattern to internalize is errdefer immediately after acquiring, switching to defer once the value is no longer being handed to the caller.

A *Node is guaranteed non-null; absence is ?*Node, which the compiler optimizes to a nullable pointer so the abstraction is free. That is the same trick Rust plays with Option<Box<T>>, and it means the null-dereference bug is a type error rather than a crash. The capture syntax if (value) |unwrapped| binds the payload only inside the branch, so unlike std::optional there is no operator* to call on an empty one — .? exists for asserting, and it traps in safe builds rather than being undefined.

The receiver is an explicit first parameter, and *Counter versus Counter is the const-correctness: a pointer receiver may mutate, a value receiver gets a copy. Initialization is a struct literal with default field values rather than a constructor, so Counter{} allocates nothing and runs no code. There is no private: everything in a struct is reachable, and the module boundary (what a file marks pub) is the only encapsulation. Note that a struct with no runtime fields is zero-sized, and struct is also how Zig spells a namespace — a file is a struct.

For a closed set of types — one you control and can enumerate — a tagged union is the right answer and is strictly better than a class hierarchy: no vtable pointer in the object, no allocation, no indirect call, and the switch is checked for exhaustiveness so adding a variant breaks every incomplete match. For an open set, where callers add types you have never seen, the answer is a hand-written vtable — a struct of function pointers plus an opaque pointer, which is what std.mem.Allocator itself is. Zig deliberately has no sugar for that, which is the most-requested feature it keeps declining.

The variants are named, so union(enum) { celsius: f64, fahrenheit: f64 } is expressible where std::variant<double, double> is useless. The switch captures the payload with |value| and is exhaustiveness-checked, so no std::visit, no if constexpr ladder, no std::get that throws, and no valueless-by-exception state. Zig also has bare union without the enum tag for C-style type punning, which is checked in safe build modes — reading the wrong field traps rather than being undefined as it is in C++.

A []const i32 is a pointer and a length, exactly like a std::span, and it accepts an array, part of an array, or heap memory. The difference is that indexing a slice is bounds-checked in Debug and ReleaseSafe, so an overrun traps at the line rather than corrupting memory — and the check disappears in ReleaseFast if you want it to. Note that arrays and slices are distinct types: [4]i32 has its length in the type and is passed by value, while []i32 carries it at runtime. Neither decays to a bare pointer, so sizeof-style bugs cannot happen.

A sentinel-terminated slice [:0]const u8 knows its length and guarantees a zero element just past the end, so it can be handed to a C function expecting const char* with no conversion and no scan, while Zig code uses .len in O(1). The sentinel is generic — [:0] is merely the common case — and the same works for arrays and pointers. C++ has std::string (which guarantees termination but is a whole object), std::string_view (which does not), and const char* (which promises nothing); none of the three puts the guarantee in the type where a caller can rely on it.

ReleaseSafe is the mode with no C++ counterpart — fully optimized, and still trapping on out-of-bounds access, integer overflow, invalid casts and unreachable code. Shipping in it means an exploitable memory error becomes a crash with a stack trace, at a cost of a few percent. C++ has no equivalent: sanitizers are separate tools with several-times overhead intended for testing, not production. And the checks are per-block, so @setRuntimeSafety(false) can disable them in one hot function while the rest of the program keeps them. Zig is not memory-safe the way Rust is; it is considerably safer than C++ in its default configuration.

Every variable must be initialized, and when you genuinely want uninitialized memory — a scratch buffer about to be overwritten, as above — you write undefined, which is greppable and reviewable. In Debug builds undefined is filled with 0xAA so a read shows up as an obviously wrong value rather than as whatever was on the stack. Compare C++, where omitting the initializer is the shorter thing to type and produces undefined behavior with at most a warning. Note for (1..5) |value| — Zig's only loop keywords are for (over sequences and ranges) and while.

@cImport invokes Zig's built-in C compiler on the header and produces real Zig declarations at compile time — no bindgen step, no hand-translated declarations to drift, and no separate build phase. That is a genuinely different position from Rust and Go, both of which need a generator or a foreign-function shim. The limits are worth knowing: C macros that are not simple constants do not translate (Zig cannot know their types), and C++ headers are not supported at all — Zig speaks the C ABI, not the C++ one, which is the same boundary every non-C++ language meets.

zig cc is a drop-in replacement for gcc or clang that accepts the same flags, so it slots into an existing Makefile or ./configure unchanged. What makes it remarkable is that Zig ships libc source for musl, glibc, and the others, plus headers for every supported target — so cross-compilation needs no sysroot, no cross binutils and no Docker image. Uber famously adopted it to cross-compile Go's cgo dependencies. If you take one practical thing from this page, take this: try it as your cross-compiler before you take on the language.

Test blocks live beside the code they exercise, so a private function can be tested without being made public and without a friend declaration — which is the thing C++ testing is most awkward about. zig test discovers and runs them; an ordinary build ignores them completely, so there is no cost in the shipped binary and no separate target. std.testing.allocator is worth knowing: it fails any test that leaks, so leak checking is on by default rather than something you set up. The philosophy matches Go's and the opposite of C++'s: one answer in the toolchain beats several good libraries.

If a + b could call arbitrary code, then reading a line would no longer tell you whether it allocates or jumps — which is the property the whole language is organized around. So operators work on numbers and nothing else. The cost lands on anything matrix- or bignum-shaped, where a.add(b).mul(c) is genuinely worse to read than a + b * c. Zig accepts that cost deliberately, and the same reasoning rules out function overloading, default parameters, and implicit conversions: in each case the call site would stop saying exactly what happens.

A closure has to store its captures somewhere, and doing that in general means allocating — which the language will not do implicitly. So state travels as an explicit parameter, or as a struct with a method, which is the same void* context pattern C uses with the types restored. The knock-on effect is that the standard library has no filter/map/reduce chain: you write the loop. Whether that is a loss depends on how much of your C++ is written in the <algorithm> style — for some codebases it is barely noticeable, for others it is the deciding objection.

Zig has not reached 1.0, has one implementation, no standard, and a track record of breaking changes in every release — the std.Io API used throughout this page replaced the previous one recently enough that most tutorials online no longer compile. Against that, C++ is ISO-standardized with several independent implementations and a compatibility record measured in decades, which is genuinely one of the most valuable things it offers. For a tool, a service you will rewrite, or a project where you control the upgrade schedule, the trade can be worth it. For a codebase that must build unchanged in fifteen years, it is not — and no amount of liking the language changes that arithmetic.