---
id: standard.language.cpp
version: 1.2.0
status: stable
---
# C++ Standard

## Apply by impact

Apply only rule groups activated by the current task or change-impact record. Do not invent
evidence for untouched surfaces; when a required gate asks about one, record why it is not
applicable.

## Rules
### Design and boundaries
- Prefer value semantics, RAII, composition, narrow interfaces, and dependency injection at external boundaries.
- Keep headers minimal; separate stable public APIs from implementation and preserve ABI promises where applicable.
### Types and data
- Use strong domain types, scoped enums, `const`, `constexpr`, spans/views, and standard containers instead of primitive obsession and raw array contracts.
- Make ownership explicit; owning raw pointers require justification. Avoid implicit narrowing and ambiguous sentinel values.
### Errors and resources
- Follow one documented exception/error policy per boundary. Preserve context and provide the basic or strong exception guarantee where relevant.
- Acquire every resource through RAII; pair C handles with reviewed wrappers.
### Concurrency and state
- Document thread safety, lock ownership/order, atomics, memory ordering, cancellation, and shutdown. Avoid data races, detached threads, and callbacks outliving owners.
### Testing
- Test public contracts, lifetime edges, move/copy behaviour, failures, serialization, concurrency, and supported compiler/configuration combinations.
- Use sanitizers and deterministic stress tests where memory or concurrency is touched.
### Performance
- Measure allocations, cache behaviour, copies, virtual dispatch, and contention before optimizing. Prefer clear data layout and algorithms over premature micro-optimisation.
### Security
- Treat sizes, indices, casts, parsing, format strings, and C/FFI boundaries as untrusted. Avoid undefined behaviour and unchecked arithmetic.
### Public API documentation
- Add project-convention or Doxygen-compatible documentation comments to changed public headers, classes, structs, enums, concepts, templates, functions, and methods.
- Document ownership, lifetime, thread safety, errors, side effects, units, valid ranges, ABI constraints, and examples when not evident from declarations.
- Do not use comments that merely repeat declarations. Private implementation details need comments when invariants, algorithms, or undefined-behaviour constraints are non-obvious.
### Tooling and delivery
- Follow the project's standard, warning, formatter, static-analysis, build-system, package-manager, exception, RTTI, and visibility policies.
- Validate clean builds, installation/exported targets, consumers, supported compilers, architectures, and build types when affected.
## Review triggers
Review missing API comments, unclear ownership, lifetime coupling, deep inheritance, broad headers,
ODR/ABI risk, unchecked narrowing, undefined behaviour, lock-order ambiguity, macro-heavy APIs,
template diagnostics disproportionate to value, and code tested on only one compiler/configuration.
## Required response
Update public API comments and generated references, make ownership explicit, reduce header
exposure, prefer composition, isolate C/FFI boundaries, add lifetime and concurrency tests, and
run warning-clean sanitizer or static-analysis builds relevant to the change.
## Exceptions
Performance-critical low-level code may use specialised ownership, templates, intrinsics, or
manual memory management when benchmarks and safety tests justify it. Generated, vendored,
compatibility-only, or externally dictated declarations may use narrowly configured exclusions.
## Evidence
Record compiler, standard, configuration, unit/integration test, sanitizer, static-analysis,
coverage, benchmark, install/export, and packaging results applicable to the change. Record
Doxygen or equivalent API-reference builds and configured documentation coverage checks.