C++

The product needs native performance, an existing engine or direct access to a platform API. C++ may be the right tool, but its control over memory, object lifetime and compilation makes engineering discipline part of the commercial cost.

C++ supports systems, embedded software, games, media, simulation and performance-sensitive libraries across many platforms. It also permits behaviour that safer managed or ownership-checked languages prevent. The decision should be based on measured constraints, ecosystem fit and a team able to operate the toolchain for years.

We use C++ for the boundary that needs it. We do not let one native component force an entire product into the same risk model.

C++ needs a product reason stronger than theoretical speed

Native compilation and control over layout and allocation can produce excellent latency and throughput. Whether that matters depends on the workload. A network service waiting on databases may gain little from rewriting its request layer in C++.

We identify the constrained operation, its input scale and a budget. A representative benchmark includes allocations, parsing, I/O and data movement rather than a small arithmetic loop. Profiling establishes which code consumes time before language selection.

Existing ecosystem can be the stronger reason. A game engine, device SDK, browser component or mature scientific library may already define a C++ boundary. Reusing it can avoid an impractical rewrite if the integration and support story are sound.

The estimate includes debugging and validation. Faster execution that takes much longer to change or recover can be a poor product trade outside the critical path.

Memory and lifetime rules define the safety case

C++ allows manual memory management, pointer arithmetic and low-level resource control. Modern C++ provides value types, RAII, containers and smart pointers that can express ownership far more safely than widespread raw allocation.

The C++ Core Guidelines recommend expressing ownership, preferring scoped objects and avoiding invalid access patterns. They are community guidance rather than a compiler-enforced safety proof.

We define who owns each long-lived resource and how borrowed references remain valid. unique_ptr communicates exclusive ownership; shared_ptr introduces shared lifetime and possible cycles, so it is used for a real ownership shape rather than to make a compile error disappear.

Boundaries that receive files, network data or plugin input need parsing limits and hostile cases. A bug in native code can corrupt process memory, which raises the assurance required for code exposed to untrusted data.

Undefined behaviour demands several forms of evidence

The C++ standard permits compilers to assume certain invalid states never occur. Out-of-bounds access, use after lifetime, data races and some arithmetic errors can therefore produce failures that change with optimisation, compiler or timing.

Warnings are enabled and treated deliberately. Static analysis catches suspicious paths without executing them. AddressSanitizer and UndefinedBehaviorSanitizer instrument test builds for classes of runtime fault, while ThreadSanitizer can expose data races with its own overhead and limitations. Clang documents these sanitizer tools.

Unit and integration tests run with production-like optimisation as well as debug settings. Fuzzing is valuable for parsers and other narrow, attacker-influenced boundaries. None of these tools proves absence of defects; overlapping evidence makes important faults easier to find.

Compiler hardening, library choices and process sandboxing reduce impact. They complement safer code rather than excuse risky ownership.

The compiler, standard library and ABI are product dependencies

“C++17” or “C++23” names a language standard, not one executable environment. Compiler versions, standard-library implementations, platform SDKs, architecture and build flags affect support and binary behaviour.

An application built entirely from source can control that set in CI. A shared library or plugin has an Application Binary Interface boundary where compiler, runtime, exceptions, allocators and layout matter. We prefer a stable C interface or carefully versioned protocol when independently built components must interoperate over time.

The ISO C++ site tracks standardisation status, while compiler support tables show which features are implemented. We choose features available across every supported toolchain rather than assuming a published standard is fully present.

Reproducible builds capture compiler images, dependencies and flags. Release symbols are retained securely so a production crash can be decoded against the exact binary customers ran.

Build-system complexity can dominate delivery

CMake is widely used to describe cross-platform C++ builds, but it does not remove platform packages, generators, compilers and link behaviour. Targets should express usage requirements so includes and flags propagate deliberately instead of through global configuration.

Dependencies are pinned with provenance and licence review. Vendoring can improve reproducibility while creating an update duty. System packages reduce local build work while varying between distributions. One project may use both with clear boundaries.

Incremental and clean build times affect team feedback. Header coupling and template-heavy libraries can make a small source change recompile much of the product. We measure the build graph before adding distributed compilation or caches.

CI covers every supported operating system and architecture that can produce different behaviour. A green Linux build is not evidence that Windows packaging or an ARM target still works.

C++ concurrency requires ownership across threads

Threads, atomics and memory-order controls allow efficient concurrency, but shared mutable state can create races and failures that resist reproduction. We start with task and data ownership, use message passing or immutable data where practical and keep critical sections small.

A lock-free structure is not automatically faster. It can increase review cost and introduce subtle correctness requirements. Benchmarks under representative contention decide whether it earns a place.

Cancellation and shutdown are product behaviours. Threads, callbacks and I/O must stop within a defined window while owned objects remain alive. A service that exits cleanly in debug but hangs under release load has not completed its lifecycle design.

We test with race instrumentation where supported and run stress cases repeatedly. Concurrency correctness cannot rely on one successful run.

Legacy C++ modernisation should follow risk boundaries

An inherited C++ system may mix old ownership patterns, compiler extensions and critical business behaviour. Rewriting it wholesale can discard years of edge-case knowledge. Leaving it frozen can make the toolchain unsupported and staffing harder.

We begin by making the current build reproducible and adding characterisation tests around high-value behaviour. Compiler warnings and sanitizers identify risky boundaries. New code can use a narrower modern subset while adapters isolate legacy interfaces.

Modules are extracted only when ownership and tests are clear. A memory-safe language can be introduced around parsers, network-facing services or new components while C++ remains for the proven engine. Foreign-function boundaries require explicit allocation, error and threading contracts.

Upgrade steps should remain deployable. A long branch that combines a compiler change, dependency replacement and architectural rewrite is difficult to verify or reverse.

Questions to answer before approving C++

• “Which measured constraint or existing ecosystem requires C++?” Name the boundary.
• “Who owns every resource crossing that boundary?” Make lifetime visible in APIs.
• “Which untrusted inputs reach native code?” Plan sanitizers, fuzzing and containment.
• “Which compilers, standard libraries, architectures and ABI must work?” Build the matrix.
• “How are dependencies pinned, patched and licensed?” Treat native supply chain as product code.
• “What concurrency model limits shared mutable state?” Test shutdown and races.
• “Can safer languages surround the critical native component?” Keep low-level risk scoped.

When C++ is a sound engineering investment

Choose C++ when native ecosystems, deterministic resource control or measured performance define an important product boundary and the team has modern C++ and toolchain capability. It is a strong choice for engines, devices, media, simulation and reusable native libraries.

The approval should include ownership conventions, sanitizer and analysis builds, supported compilers and production crash diagnosis. Those controls are part of delivering the language safely.

When a safer managed language should carry more of the product

Use C#, Java, Go or another managed or memory-safe language for standard services and business workflows where network and data design dominate performance. A native extension can retain the narrow hot path.

Avoid C++ where the organisation cannot staff review, builds and platform debugging. Syntax familiarity from older code is not evidence of modern ownership practice.

And do not rewrite stable native code solely to adopt the newest standard. Upgrade because support, safety, delivery or product capability improves measurably.