# The C+ Manual C+ compiles to native code through LLVM. It has no garbage collector, no exceptions, no closures, no overloading, no implicit conversions, and no `null`. Memory is managed manually, policed by a borrow checker, with C ABI compatibility for FFI. The point of every one of those choices is the same: each program stays **locally legible**. You can read one function and know exactly what it does, without chasing implicit destructors, hidden conversions, or surprise allocations. The compiler enforces that property. If you slip, the diagnostic tells you precisely where and why. ## Start here Three ways in, depending on what you need right now: - **Try it in 5 minutes** — [run C+ in the browser](/playground) with nothing installed, or [install `cpc`](/docs/getting-started), compile a hello world, and trigger a compiler diagnostic. - **Judge whether it's real** — start with the [reproducible proofs](/prove), then a complete [ray tracer](/examples/raytracer), a C+ object [dropped into a C build](/examples/c-abi-consumer), an [allocation-free control kernel proven on an ESP32](/examples/esp32-realtime-pid), and the [GitHub releases](https://github.com/netdur/cplus/releases). - **Understand the language** — the [language specification](/docs/spec), [ownership](/docs/ownership) and the [borrow checker](/docs/borrow-checker), [FFI](/docs/ffi), and how [packages](/docs/packages) carry everything beyond the core. ## C plus packages The name is the architecture: C+ is **C (the C ABI) plus packages**. The language core is small on purpose. It gives you types, ownership, and a way to speak the C ABI in both directions, and then stops. Everything else, **including the standard library**, lives in packages. `stdlib` is itself a package under `vendor/`, not a language built-in, and the same is true of the platform bindings, allocators, parsers, and math helpers. Capability grows by adding a package, not by growing the language. That is what keeps the surface you have to read, and a model has to generate, small and predictable. Each package has its own page under [Packages](/docs/packages). > **The language surface is small on purpose.** The core gives you types, ownership, and the C ABI, then stops. New capability lands in packages and tooling rather than the core, so a person can audit the whole surface and a model can learn it once. [Builder blocks](/docs/builder-blocks) are a recent example — a tiny construction syntax the compiler owns, with packages supplying the meaning. > This is a single, living manual that tracks the latest release of C+. C+ is pre-1.0 and moving quickly, so the surface grows between releases; this page always reflects the current one. Every page is also available as raw Markdown — append `.md` to its URL, or use the "View as Markdown" link. ## Platform support The toolchain **runs on** these hosts: | Host | Status | |---|---| | macOS M-series | Supported | | Linux x86-64 | Supported | | Windows x86-64 | Supported | | Linux ARM | Planned | | Windows ARM | Planned | …and **cross-compiles** to these targets with `--target` (see [Targets & cross-compilation](/docs/targets)): | Target | Status | |---|---| | iOS (`ios-arm64`, simulator) | Supported | | Android (`android-arm64`) | Supported | | ESP32 (`esp32-xtensa`) | Supported | GUI backend support: | Backend | Status | |---|---| | macOS AppKit | Supported | | iOS UIKit | Supported | | Linux GTK+ | Planned | | Windows Win32 | Planned | ## Locked principles These principles underlie every C+ design decision. They are fixed, not open questions. | # | Principle | Why | |---|---|---| | 1 | No `null` anywhere | Use `Option[T]`. Avoids the billion-dollar mistake. | | 2 | No closures or lambdas | Use a named `fn` plus `(fn_ptr, user_data)`. Eliminates capture semantics. | | 3 | No `&T` / `&mut T` reference types | The caller relation is a parameter marker (`ref` / `take` / bare), not a type. | | 4 | No exceptions | Errors are tagged-union values, matched exhaustively. | | 5 | No implicit conversions | Every width change requires `as`. | | 6 | No operator or function overloading | One name, one signature. | | 7 | No macros, decorators, or comptime | Attributes are pure metadata. | | 8 | No `class` or `function` | Use `struct` plus `impl`, `fn`. Locals are `let` / `var`. | | 9 | Mutability is explicit | `var` is a local, `static` is a global, `ref` is write-back. No `mut`. | | 10 | Generics use `[T]`, not `` | Avoids the `a(c)` grammar ambiguity. | | 11 | Explicit `return` | No implicit tail returns at the function level. | | 12 | `::` for types, `.` for instances | Strict separation. | | 13 | Public by default, private via `_` | A leading `_` marks a file-private item; `export` marks the C-ABI surface. Hiding is intentional, not accidental. | ## Where to go next - [Getting started](/docs/getting-started) compiles and runs your first program. - [Ownership](/docs/ownership) covers the part of C+ that differs most from C. - [The borrow checker](/docs/borrow-checker) explains the one rule that makes data races a compile error. - [Error handling](/docs/error-handling) shows how fallible code works without exceptions.