C++ vs Rust for an existing native component: ownership, FFI and adoption

Compare the practical consequences

Scroll sideways to compare all columns on a smaller screen.

↑ Back to sections

Should an existing C++ component stay in C++?

Keep a supported C++ implementation that meets its requirements. Pilot Rust at a narrow ownership boundary when compiler-checked borrowing addresses a concrete maintenance problem and the team can support both toolchains.

Consider a hypothetical image decoder used by a C++ desktop application. The caller expects a bounded byte buffer, an error result and predictable release of resources. The decoder also depends on a vendor library available only as a supported C++ binary. Replacing its outer language does not remove that dependency. First locate the failure: malformed input handling, ownership at the callback boundary, an algorithmic bottleneck or unsupported platform builds. Those are different projects. A language pilot is useful only when it tests the identified failure mechanism.

A viable first boundary could be a new input-validation module with a small byte-oriented interface and no retained caller pointers. Keep the existing decoder as the reference implementation. Run both on an agreed corpus and compare accepted/rejected inputs and output bytes before discussing wider adoption. The proposed pilot is an engineering experiment, not evidence that Rust will prevent every decoder defect. Staying in C++ can be the better outcome if a local ownership repair meets the same requirement with less support burden.

Read the source: C++ Core Guidelines: interfaces and resource management · Rust Book: ownership

↑ Back to sections

What does ownership change for the component author?

C++ expresses ownership through value types, RAII and chosen API conventions. Safe Rust checks borrowing and ownership constraints, while unsafe implementations and foreign code still need a sound contract.

In the decoder example, distinguish an input borrowed for one call from an output that survives the call. A C++ span or string_view can describe a borrowed view without extending its storage lifetime. A Rust slice reference carries lifetime constraints within checked Rust code. Neither description authorizes the callee to retain a pointer after the caller frees the buffer. Write the no-retention condition into the foreign interface and test it through every callback and asynchronous path.

Inside a Rust implementation, a returned Vec owns its allocation and a borrowed slice cannot simply outlive its owner. At the foreign boundary, raw pointers no longer carry that proof to the C++ caller. A safe Rust wrapper must establish the pointer validity, aliasing and lifetime conditions its unsafe calls require. The practical gain is containing unchecked obligations in a small reviewed region; it is not turning every foreign dependency into safe Rust by importing it.

Read the source: Rust Book: ownership · Rust Book: unsafe Rust boundaries · Rust Reference: undefined behavior and soundness

↑ Back to sections

How should a buffer cross the C++/Rust boundary?

Prefer an explicit borrowed input and caller-owned output for a first pilot. Specify lengths, capacity, empty buffers, overlap, retention and failure writes. Keep allocation and destruction on the same documented side.

Here is a proposed C-facing decoder contract, not a drop-in binding. The caller supplies live input bytes and writable output capacity. Nonzero lengths require valid pointers; a null pointer is allowed only for a corresponding zero length, and the implementation must branch before constructing a Rust slice from a null pointer. Input and output must not overlap. The operation is synchronous and retains neither pointer. A reported required size must be checked against a product limit before a caller allocates memory. The written_or_required argument must point to aligned live size_t storage disjoint from both byte ranges. Each byte range must lie within one live allocation, with non-wrapping address arithmetic and a byte size no greater than isize::MAX for construction as a Rust slice. Input bytes must be initialized; output bytes must also be initialized before constructing a Rust mutable byte slice and valid for exclusive reads and writes and remain unavailable to other readers or writers during the call. Length arithmetic and product limits are adapter checks. Actual pointer validity and lifetime are caller obligations, not facts an adapter can discover by inspecting an address.

Define status codes before writing adapters: OK means written is within output capacity; NEED_SPACE returns a required length without publishing partial output; BAD_INPUT publishes no decoded data. Define whether output bytes are untouched on failure or simply unspecified and forbidden to read. For this pilot choose untouched-on-failure, which requires completing into staging before copying, or a sizing/validation pass that establishes a subsequent bounded write phase cannot fail. If a library must allocate output instead, provide its matching release function and wrap that handle in C++ RAII. Never construct a Rust Vec from an arbitrary C++ allocation or delete Rust-owned storage with C++ delete. Set written_or_required to the produced byte count on OK, the required capacity on NEED_SPACE, and zero on BAD_INPUT or INTERNAL. Internal failures must preserve the same untouched-output rule; staging must complete before the output commit.

/* Proposed C header, contract described above. */
/* status: 0 OK, 1 NEED_SPACE, 2 BAD_INPUT, 3 INTERNAL */
int decode_bytes(const unsigned char *input, size_t input_len,
                 unsigned char *output, size_t output_capacity,
                 size_t *written_or_required);
/* Required: aligned live size_t, disjoint from input/output. */
/* OK: count; NEED_SPACE: required; BAD_INPUT/INTERNAL: zero. */

Read the source: Rustonomicon: foreign function interfaces · Rust Reference: type layout and representation · Rust slice: from_raw_parts safety requirements · Rust slice: from_raw_parts_mut safety requirements

↑ Back to sections

What does a C ABI solve, and what remains?

A C ABI can give both toolchains a shared calling convention for supported types. It does not establish matching layouts, ownership, supported targets or a safe exception and panic policy.

Keep the example boundary to byte pointers, size_t-compatible lengths and explicitly agreed integer statuses on the same target. Do not export std::string, std::vector, Rust String or ordinary Rust enums as if their internal representation were a C contract. For a shared record, define fields and representation deliberately, then compile consumer fixtures that check size, alignment and offsets on each supported target. A matching development laptop build does not certify a vendor SDK, Windows target or another standard-library ABI.

Keep ordinary decode failures as status results. Contain C++ exceptions within the C++ adapter before returning through a non-unwinding C boundary. On the Rust side, a deliberate panic policy must account for build configuration: catch_unwind only handles unwinding panics, not aborting panics, and does not turn arbitrary foreign exceptions into ordinary errors. Do not promise that allocation failure or process abort becomes INTERNAL. If the product requires fault containment even for process termination, evaluate a separate process boundary instead of claiming an in-process wrapper provides it.

Read the source: Rust Reference: type layout and representation · Rust standard library: catch_unwind limits

↑ Back to sections

How can the team compare performance fairly?

Measure the whole proposed call path with equivalent behavior and representative inputs. Include boundary copies, allocation, malformed inputs and build settings; do not infer speed from either language name.

For the hypothetical decoder, record a corpus covering small images, large images, rejected headers, maximum permitted dimensions and repeated calls. Compare output identity or a defined error equivalence before timing. Measure wall time distributions, peak resident memory, allocations if available and the number of copied bytes across the boundary. Report input distribution and sample counts. A faster parser with different validation or less work is not the same product.

Use deployment-like optimization settings on the same machine and record compiler versions, target features and linked native libraries. Separate cold process startup from steady repeated calls. Choose acceptable limits before reading results: the product owner may tolerate a small CPU cost for a proven defect reduction but reject a doubling of peak memory. No measurements are supplied here; this is a worksheet for collecting evidence, not a benchmark result or performance ranking.

Corpus case | Output/error equivalence | p50/p95 time | Peak memory | Copies
Small valid |                            |              |             |
Large valid |                            |              |             |
Bad header  |                            |              |             |
At size cap |                            |              |             |
Build/target/library versions:
Pre-agreed acceptance and reversal limits:

Read the source: Cargo: profiles and optimization settings · Cargo: native build scripts

↑ Back to sections

What is a reversible migration sequence?

Freeze the caller contract, implement one replaceable module, prove behavioral parity and keep the previous path usable until the pilot meets its support and measurement gates.

Start with the existing decoder tests and add the missing malformed-input and ownership cases. Capture outputs, error categories and resource limits as a contract. Build a new implementation behind the same narrow internal interface. Run comparison tests in CI using stored fixtures, not duplicate production processing that could expose customer data. If the implementation has side effects, define their test substitute before exercising both paths. The pilot boundary should avoid a file-format or persisted-state migration.

Promote only after both language owners can debug a failed call, reproduce the build and release a correction. A reversal condition might be unsupported vendor linkage on a required target, a memory limit exceeded on the agreed corpus, or support that depends on one unavailable engineer. Record who can select the retained implementation and how its compatibility is kept tested. A fallback that no longer compiles after several months is not a reversal path.

Read the source: Cargo: native build scripts · C++ Core Guidelines: interfaces and resource management

↑ Back to sections

What should the interview and hiring process assess?

Assess the actual ownership boundary and failure modes the role will maintain. Language syntax alone does not establish that someone can own native interoperability or production debugging.

Give a candidate the proposed decoder contract and ask them to locate the owner of every allocation, the last valid use of each pointer and the behavior on NEED_SPACE. For a C++ role, probe invalidation, RAII and exception guarantees. For Rust, probe borrow design, error types and the unsafe obligations behind a safe wrapper. An excellent answer may recommend keeping the existing implementation and fixing its lifetime bug.

The linked interview guides provide worked language mechanisms; the hiring hub helps choose an actual role brief, and the budget worksheet separates compensation from other hiring costs. There is no dedicated systems-role scorecard on this site yet, so these general tools should not be presented as a validated C++/Rust assessment packet. If the job includes SDK integration, cross-compilation or constrained hardware, add a role-specific exercise based on that work and state those requirements in the brief.

Read the source: C++ Core Guidelines: interfaces and resource management · Rust Book: unsafe Rust boundaries

↑ Back to sections

How should C++ and Rust salary evidence affect the decision?

Use each linked technology cohort as advertised-pay context for relevant posts. Do not read a difference between the cohorts as the cost or benefit of switching the component language.

A technology-tagged job can mention several languages, cover multiple seniority levels and advertise a salary interval with only one endpoint. The same post may appear in both cohorts. Location, work mode, company and role mix can differ. This page preserves separate salary links and any existing sample/overlap gates; it does not turn tagged posts into comparable matched employees.

For a hiring decision, open the original relevant posts, check the scope and currency basis, then build a budget for the actual role. A native systems position maintaining a vendor SDK may not match a backend Rust vacancy. The language decision should combine implementation evidence, support ownership and a hiring plan for that work. A headline salary median cannot establish a migration ROI or guarantee that a person with either tag can do the job.

Read the source: StartupJobList: salary evidence and methodology

↑ Back to sections

Keep exploring