C++.CodeCompared.To/Rust

Rust has no preprocessor and no headers, so there is nothing to include — println! comes from the prelude, which is injected into every module automatically. The trailing ! marks it as a macro rather than a function, which is how it can typecheck its format string at compile time; a mismatched placeholder is a compile error, not a runtime surprise. Returning from main is implicit, and the process exit code is 0 unless main returns an Err.

There is no Rust equivalent of the CMake-versus-Meson-versus-Bazel question, and no equivalent of hunting a header down through find_package. The cost is the flip side of the same coin: Cargo assumes it owns the build, so slotting Rust into an existing CMake tree means driving Cargo from CMake rather than the reverse. Note also that cargo test needs no separate framework — the test runner is part of the toolchain.

Everything in a Rust module is private to that module unless marked pub — including struct fields, which is why x and y need it here. A module also compiles as part of one crate rather than being textually included, so there is no header/implementation split, no include guards, no one-definition rule to violate, and no possibility of two translation units disagreeing about a type because they saw different #defines.

This sounds like a cosmetic swap and is not. Because the annotated case is the rarer one, mut actually gets written and actually gets noticed, whereas const-correctness in C++ is a discipline that erodes the moment one function in the call chain forgets it. A Rust reviewer can find every place a value changes by grepping for mut.

There is no int in Rust and no <cstdint>-style second set of names, because the primary names already carry the width: i8, i16, i32, i64, i128, and the u family for unsigned. Only usize/isize vary by platform, and they exist for exactly the reason std::size_t does. The default when inference has nothing else to go on is i32.

Rust performs no implicit numeric conversions at all: not signed to unsigned, not narrowing, not even i32 to i64. Every conversion is an explicit as, which means the sign-comparison trap above cannot be written by accident. The cost is real — arithmetic that mixes widths gets noisier — but the class of bug that -Wsign-compare exists to warn about simply does not compile.

Rust has no undefined overflow. The default + panics in a debug build and wraps in a release build, and when you want a specific behavior you name it: checked_add returns Option, wrapping_add wraps, saturating_add clamps, and overflowing_add returns both the result and a flag. The important part is that no choice among these is ever undefined, so the optimizer cannot reason backwards from "this cannot happen."

The compiler performs a definite-initialization analysis over the whole control-flow graph, so a variable assigned in an if branch but not the else is rejected at the point of use. This is one of the borrow checker's quieter jobs and it removes an entire category of C++ bug without any runtime cost — the check is purely static.

The one difference is the one that matters. A std::string_view that outlives its std::string is a dangling view and the compiler will not stop you — this is one of the easiest C++ footguns to fire. A &str carries a lifetime, so the same mistake does not compile. Note also that taking &owned where &str is wanted works through deref coercion, the closest thing Rust has to a user-visible implicit conversion.

A std::string is a bag of char with no encoding attached, so counting characters means writing the UTF-8 decoder above. A Rust String is guaranteed valid UTF-8 — the constructors that could break that invariant return a Result — so .chars() can exist and be correct. The same guarantee is why greeting[0] does not compile in Rust: it would have to return half a character, so the language declines to offer it.

The two grammars are deliberately close cousins — both descend from Python's. Two differences to note: Rust's float precision spec is {:.2} with no trailing type letter, and because format! is a macro rather than a function it validates the string against the argument list at compile time. A wrong placeholder count is a compile error in Rust; in C++ it is a compile error only when the format string is a constant expression, which is the common case but not the only one.

The layouts are identical, so this really is the same data structure with different spelling. Two things to watch: iterating &readings rather than readings borrows the vector instead of consuming it (writing for reading in readings would move it, and the vector would be unusable afterwards), and push requires mut where C++ needs only a non-const reference.

Mutating a container while iterating it is undefined behavior in C++ and a compile error in Rust, and the rule that produces the error is simple enough to hold in your head: any number of shared borrows, or exactly one mutable borrow, never both. That single rule also rules out the aliasing that makes C++ optimizers so conservative, which is why Rust can pass noalias to LLVM on ordinary references.

Rust's get returns Option<&V>, so the absent case is a value you must handle rather than a default-constructed entry you did not ask for. Indexing with [] does exist and panics on a missing key, matching at() rather than operator[]. When you do want insert-if-absent, the entry API is explicit about it: *stock.entry("sprocket").or_insert(0) += 1.

A &[i32] is a fat pointer — address plus length — exactly like a std::span, and it accepts a Vec, a fixed-size array, or part of either via &readings[1..3]. The difference is again lifetimes: a span outliving its vector is a dangling read that compiles, while a slice outliving its Vec does not compile. Note that sum ends in an expression with no semicolon and no return, which is the ordinary Rust style.

Almost everything in Rust is an expression: if, match, loop, and a bare block all produce values. The practical payoff is that initialization stays a single let even when the logic needs several lines, so a variable that is conceptually constant does not have to be declared mutable just to be filled in afterwards. Both arms must have the same type, which is what makes it type-check.

The replacement for a counted loop is a range: 0..3 is half-open, 1..=3 is inclusive, and .rev() counts down. Breaking out of nested loops uses a lifetime-style label ('outer) on both the loop and the break, which is what C++ needs goto or a flag variable for. There is no goto in Rust, and labeled break/continue covers the cases people actually used it for.

Rust's match does not fall through, so there is no break to forget. It is also exhaustive: leaving out the _ arm here is a compile error because the compiler cannot prove every i32 is covered. That exhaustiveness is what makes match genuinely more powerful than switch rather than merely safer — see the enum rows below, where adding a variant turns every incomplete match in the codebase into a compile error.

Two things differ from C++ habit. There is no forward declaration and no ordering requirement, because a Rust module is parsed as a whole rather than top to bottom, so a function may call one defined below it. And the final expression is the return value when it has no semicolon — second here — so explicit return is normally reserved for early exits, as above. Parameters cannot have default values; overloading by arity is done with an Option parameter or a builder.

A C++ lambda capturing by reference and then stored past the enclosing scope is a dangling reference, and [&] makes that mistake a single character wide. Rust infers the weakest capture the body needs, and the borrow checker then refuses to let the closure outlive the borrow. When you want C++'s [=] semantics — take ownership of everything — write move |value| { … }, which is required for closures sent to another thread.

The C++ habit is std::function, which is convenient and costs an indirect call plus, often, an allocation. The Rust habit is impl Fn, which is a generic parameter in disguise: it monomorphizes, so the closure inlines and nothing is allocated. Rust's equivalent of std::function is Box<dyn Fn(i32) -> i32>, and you reach for it only when you genuinely need to store differently-typed callables together. The three traits Fn, FnMut and FnOnce distinguish closures that read, mutate, or consume their captures.

The const qualifier moves to the front and becomes part of the receiver: &self is a const method, &mut self is a non-const one, and self by value consumes the object — a receiver C++ can only approximate with an rvalue-ref-qualified overload. new carries no special meaning; it is a plain associated function, and a type is free to have several constructors with descriptive names instead of a pile of overloads.

A Rust type has no copy, no comparison and no printing until you ask, and asking is a derive attribute naming exactly what you want. Clone is an explicit .clone() call; Copy additionally makes assignment duplicate rather than move, and is only allowed for types where a bitwise copy is correct. That last restriction is the point: a type owning a heap buffer cannot be Copy, so the accidental deep-copy-on-assignment that a C++ copy constructor performs silently cannot happen.

Destruction is deterministic, runs at end of scope in reverse declaration order, and composes through struct fields exactly as in C++. The differences are small: the trait is named Drop rather than a tilde method, you cannot call it directly (use std::mem::drop(value) to destroy early), and a type with a Drop implementation cannot be Copy. The leading underscore on _outer only silences the unused-variable warning; binding to bare _ would drop it immediately, which is a genuine gotcha.

What survives is the half that people actually wanted: an interface with default method bodies, which is a trait. What does not survive is inherited state; a Rust type that wants a base class's fields holds it as a member and forwards, which is the composition-over-inheritance advice C++ style guides give anyway. Box<dyn Shape> is the std::unique_ptr<Shape> of this example: a fat pointer carrying data and vtable, dispatched dynamically.

The important difference is invisible here and shows up on the next commit. Add a Status::Archived variant and the Rust match stops compiling, at every site in the codebase that failed to handle it. The C++ switch compiles and silently does nothing — -Wswitch catches this case, but only when there is no default: arm, and a default: is exactly what most real switches have.

Everything std::variant does, a Rust enum does with first-class syntax: no std::visit, no if constexpr ladder, no std::get that throws, and no valueless-by-exception state. The variants are also named — Number and Text rather than int and std::string — so a variant holding two integers with different meanings is expressible, which std::variant<int, int> is not. This one feature is why Rust needs no null and no exceptions; the next two rows are both just enums.

The API surface is nearly a rename: value_or is unwrap_or, and_then is and_then, has_value is is_some. The behavioral difference is that dereferencing an empty std::optional is undefined behavior while unwrap() on a None panics with a message and a backtrace. And because Rust has no null pointer for safe references, Option is the only way to express absence — there is no second mechanism to also check for. Option<Box<T>> is optimized to a single nullable pointer, so the abstraction is free.

A match arm is a pattern, so it can test literal values, bind names, and nest — Some((row, 0)) is a valid arm. The if after a pattern is a guard, evaluated only when the shape matches. Patterns also appear in let, in if let, in while let, and in function parameters, so the same small syntax covers what C++ spreads across structured bindings, std::visit, and if constexpr.

A C++ template body is checked at instantiation, which is why a mistake surfaces as a wall of errors pointing into the standard library rather than at your code. Rust checks the generic body once against its bounds, so value > best is only allowed because PartialOrd was declared. The practical effect is that the error arrives at the definition and names the missing bound. C++20 concepts close much of this gap by constraining the interface, but the body is still checked late.

A C++ concept describes a shape structurally — "whatever type supports left + right". A Rust bound names an explicit trait the type must have declared it implements. Structural is more flexible; nominal means a type cannot satisfy a bound by accident, and it means the operator itself is a trait method (+ is Add::add), so no separate requires clause is needed to talk about it. The Output = Value is an associated type constraint, which is roughly a concept's return-type requirement.

The vtable is stored differently, and it is worth knowing which. A C++ polymorphic object embeds a vtable pointer in the object itself, so sizeof grows and the object is never trivially copyable. A Rust dyn Trait reference is a fat pointer: the vtable pointer lives beside the data pointer, not inside the object, so the concrete English struct is zero bytes and carries no hidden field. The trade is that dyn Trait is unsized, which is why it always appears behind & or Box.

This is the extension-trait pattern, and it is why so much of Rust's ecosystem composes without wrappers: rayon adds .par_iter() to every standard collection, and itertools adds a dozen adapters to every iterator, all without touching the original types. The guard rail is the orphan rule — an impl is only allowed if either the trait or the type is local to your crate — which is what prevents two libraries from defining conflicting implementations for a pair they both merely import.

C++ leaves a moved-from object in a "valid but unspecified" state, which means reading it is well-defined but the value is whatever the implementation chose — usually empty, not always. Rust moves by default for any non-Copy type, and then statically marks the source as moved-out, so use-after-move is a compile error rather than a convention. That also means no std::move and no rvalue references: there is nothing to opt into, because ordinary assignment already moves.

Two things are new. First, the borrow is visible at the call site — &mut message tells a reader this call may change the argument, which the C++ call modify(message) does not. Second, borrows carry lifetimes the compiler tracks: a reference cannot outlive what it points at, so returning a reference to a local, or holding one across a reallocation, does not compile. That check is what makes the aliasing rule in the next row enforceable.

C++ has restrict only as a compiler extension for pointers, and using it is a promise the compiler cannot check — break it and you get miscompilation. In Rust the guarantee is structural: &mut T is unique by construction, so every one of them is emitted with noalias, unconditionally and safely. Calling this function with the same vector twice is not a bug you have to remember to avoid; it does not compile.

The fix is the same in both languages — return by value — but the enforcement differs. C++ emits -Wreturn-local-addr, which is a warning you can ignore and which does not fire through even one layer of indirection. Rust cannot express the broken version: the return type would need a lifetime, and there is no input lifetime to tie it to. Returning the String moves the heap buffer to the caller with no copy, exactly as C++ does under return-value optimization.

The difference worth noticing is nullability. A std::unique_ptr can be null, so every dereference is a potential crash; a Box<T> never can, which is why the optional link is spelled Option<Box<Node>>. That is not extra cost — the null-pointer optimization makes it the same one word — it just moves the "might be absent" fact into the type where the compiler can enforce the check. Note also that no std::move appears: putting tail into head moves it because that is the default.

std::shared_ptr always uses an atomic refcount, because it cannot know whether you will share it across threads — so single-threaded code pays for thread safety it does not use. Rust splits the type: Rc is non-atomic and cheap, Arc is atomic and thread-safe, and the compiler enforces the distinction by refusing to send an Rc across a thread boundary. Note also that the clone is explicit: Rc::clone(&document) makes the refcount bump visible, where C++ copy-assignment hides it.

C++ answers with mutable, which simply exempts the field from const with no further conditions. Rust answers with a type: Cell<T> for copyable values, and RefCell<T> when you need a reference, which moves the borrow check from compile time to runtime and panics on violation. The distinction that matters is that neither is Sync, so a struct containing one cannot be shared across threads — the escape hatch is bounded, whereas mutable silently creates a data race the moment two threads call the getter.

A lifetime parameter changes no code and costs nothing at runtime; it is purely a claim in the signature about which input the returned reference borrows from, which the compiler then checks on both sides. C++ has the same relationship in this function — the returned string_view really does point into one of the arguments — it just has no way to write it down, so the invariant lives in a comment or in nobody's head. Most functions need no annotation at all: the elision rules infer the common cases, and a signature with one reference in and one out is inferred automatically.

The <'a> on the struct is that unwritten rule, written down and checked. It propagates: anything holding an Excerpt also gets a lifetime parameter, which is the compiler tracking the same obligation you were tracking by hand. The practical advice is the same as in C++ — reach for an owned String field unless the borrow is measurably worth it — but where C++ makes borrowing look free and defers the cost to a crash, Rust makes the cost visible in the type up front.

The consequence a C++ programmer will feel first is that the signature tells the truth. noexcept aside, any C++ function may throw, so every call is a potential early exit and exception safety is a property you reason about globally; a Rust function returning i32 cannot fail, full stop. The cost is visible plumbing, which is what the ? operator in the next row exists to reduce. There is no unwinding through the happy path either, so there is no "zero-cost until it throws" cliff.

value? expands to "if this is Err, convert the error type and return it; otherwise evaluate to the Ok payload." That conversion step is what lets a function returning a general error type absorb several specific ones. Compared with exceptions you trade invisibility for auditability: every place a function can bail out is marked with a ?, so reading for error paths is a search rather than an analysis. ? works on Option too, propagating None.

The C++ default, operator[], does not check; you opt into checking with .at(). Rust inverts this: readings[10] is always checked and panics, and you opt out of the check with get_unchecked, which requires unsafe. A panic unwinds by default and can be caught with catch_unwind, but that exists for thread and FFI boundaries rather than for control flow — the intended response to a panic is to fix the bug.

Both are lazy — nothing runs until the pipeline is consumed — and both compile away entirely, so the loop is as fast as one written by hand. The syntax differs in that Rust uses method chaining rather than the pipe operator, which means the adapters read in call order and need no views:: qualification. The consuming step is explicit in both: a range-for in C++, and a terminal method like sum, collect or for_each in Rust. Forgetting the terminal step in Rust produces an unused-value warning, since an iterator that is never consumed does nothing.

collect() is generic over its return type, which is unusual and worth internalizing: the same call produces a Vec, a HashMap, a String, or a HashSet depending only on the annotation, and it is often the only place a Rust program needs an explicit type. There is one especially useful case: collecting an iterator of Result into Result<Vec<_>, _> stops at the first error and returns it, which is a whole error-handling pattern in one method call.

The index-based loop has two failure modes the Rust version cannot have: it reads scores[index] without checking that scores is as long as names, and the </<= boundary is written by hand every time. zip stops at the shorter of the two, and enumerate supplies the counter, so neither mistake is expressible. C++23 has std::views::zip and std::views::enumerate, which close this gap when you can use them.

The C++ workers write into a shared vector captured by reference — correct here only because the indices happen not to overlap, which nothing checks. Rust's spawn requires move, so captures are owned, and its 'static bound makes borrowing a local into a thread a compile error; the way out is that join() returns the closure's value, so no shared slot is needed at all. Two smaller differences: forgetting to join a std::thread calls std::terminate, while dropping a Rust JoinHandle simply detaches. And when you genuinely do want to borrow a local, thread::scope proves the threads finish first and permits it.

A std::mutex guards data only by convention — the association between guard and total exists in the programmer's head, and touching total without locking compiles fine. A Rust Mutex<T> contains the T, so the only way to obtain a reference is to lock, and the guard returned by lock() releases on drop exactly like std::lock_guard. The Arc wrapper is what lets several threads own the mutex; the compiler rejects Rc here, because Rc is not Send.

Rust encodes thread-safety in two marker traits the compiler applies automatically: Send means a value can move to another thread, Sync means &T can be shared with one. Rc is neither, RefCell is Send but not Sync, Mutex<T> is both when T is Send. Because these propagate structurally, a struct built from race-unsafe parts is itself rejected at the thread boundary. This is the check C++ has no equivalent of — std::thread will hand a lambda anything you capture.

A macro_rules! macro matches on parsed syntax, not tokens of text, so its arguments are expressions and it can bind each one to a local exactly once. It is also hygienic: the left and right above cannot collide with variables at the call site, which is what the C++ convention of __ugly_names inside macros is trying and failing to achieve. Conditional compilation moves to the #[cfg(...)] attribute, which is evaluated by the compiler rather than a separate text-substitution pass.

Those five are: dereferencing a raw pointer, calling an unsafe function, accessing a mutable static, implementing an unsafe trait, and reading a union field. Everything else — borrow checking, type checking, lifetimes — still applies inside the block. The value is not that the operations are rare but that they are marked: a memory-safety bug in a Rust program is, by construction, inside an unsafe block or in a library's, which turns an audit of the whole program into an audit of a few hundred lines. In C++ every pointer dereference is in that category and none of them are labeled.

C++ gets C declarations for free by including the header; Rust has no header parser, so the signature is re-declared (in practice bindgen generates this from the header for you). Calling into C is unsafe because the compiler cannot verify what happens on the other side. Going the other way is symmetric: extern "C" plus #[unsafe(no_mangle)] is C++'s extern "C". What Rust has no equivalent of is direct C++ interop — templates, overloads and exceptions have no stable ABI to bind against — so the two normally meet across a C-shaped boundary, which is exactly what cxx and similar crates automate.