R.CodeCompared.To/C++

The habit to carry across is the opposite of the one R teaches: at an interactive prompt an expression's value is printed automatically, and in a script it is not. That is the most common reason an R example appears to do nothing. C++ has no auto-printing at all, so every value that reaches the screen does so because a line of code sent it there.

For an R programmer the compile step is the unfamiliar cost, and it is worth being realistic about it: the fast edit-and-look loop you have at the console is gone, and a real C++ build takes seconds to minutes rather than nothing. What you get is that every name, every type and every argument count is checked before anything runs, and that the result is machine code with no interpreter overhead per operation — which is the whole point of the Performance section at the end.

The reframing worth doing early: R's vectorized operators already are the C++ loop, written once inside R's own C sources. So "vectorize it" and "write it in C++" are two ways of reaching the same machine code, and the reason to reach for C++ is the case where no vectorized formulation exists — a recursion, a simulation whose step depends on the last, a loop with early exit. Note also that a length-one vector is R's scalar, which is why length(5) is 1 and why R has no distinction to lose.

Two differences worth knowing. The C++ version is lazy and materializes nothing: squaresOfEvens is a recipe, and the work happens as the loop pulls values through, so there is no intermediate vector the way evens is one in R. And the lambda is checked at compile time against the element type, so an operation the type does not support is a build error rather than a run-time one. Add | std::ranges::to<std::vector>() when you actually want the vector.

R's copy-on-modify is a performance strategy that is invisible until it is not — the classic R slowdown is a loop that grows a vector, where each x[i] <- value may copy the whole thing. C++ makes the copy explicit and therefore predictable, and gives you three ways to avoid it: a reference (&), a const reference for read-only access, and std::move to hand ownership over. The habit worth forming is const std::vector<double>& for any parameter you only read.

The difference is what happens when you forget. R's c(values, index) allocates a new vector and copies on every iteration, which is quadratic; std::vector::push_back grows geometrically, so it is amortized constant and forgetting reserve costs a small constant factor rather than an order of magnitude. That is why "preallocate" is R advice and "reserve when you know the size" is merely a C++ nicety.

The floating-point surprise is shared, because both use IEEE 754: 0.1 + 0.2 != 0.3 in R, in C++ and everywhere else. What changes is that C++ has several integer sizes and no automatic promotion to a bigger one, so overflow is possible where R's doubles would simply lose precision — and 🚨 signed overflow in C++ is undefined behavior rather than a wrong number, which R has no equivalent of. Note also that bool prints as 1, not TRUE.

This is one of the sharper losses when porting statistical code, and it needs a design decision rather than a translation. The options are: use NaN and be careful (fine for doubles, unavailable for integers and strings), carry a parallel vector of flags (which is what R does internally for integers), or use std::vector<std::optional<T>> and pay a byte per element plus a branch per access. Rcpp's NumericVector preserves R's NA properly, which is one of its quieter advantages over plain C++.

Negative indexing, logical subsetting and values[c(2, 4)] selection by index vector are all R conveniences with no C++ equivalent; each becomes an explicit loop or a range pipeline. And values[10] on a four-element vector is not an error either — .at(10) is the checked version that throws. An R programmer's instinct that an out-of-range index yields NA is the single most dangerous habit to carry across.

Most R programmers have been bitten by this at least once — a length mismatch that should have been an error becomes a silently recycled result, and the warning for a non-dividing length is easy to miss in a long script. Writing the intent out is more code and it is code that cannot surprise you. The general shape of the trade on this page: R makes the common case short and the failure quiet, C++ makes both explicit.

That layout choice matters more than it looks. A struct of vectors means an operation on one column touches only that column's memory, which is why it is fast and why it matches how R, pandas and Arrow all store tabular data. A vector of structs is the natural object-oriented shape and is worse here for the same reason. What you lose is everything a data frame does for you — named columns by string, factors, subset, merge, aggregate, printing — all of which become loops or a library such as Arrow.

The two replacements, and when each applies: a struct when the fields are known (nearly always — and you get compile-time checking and a misspelled field as a build error), or std::map<std::string, X> when the keys genuinely vary at run time, which requires every value to be the same type X. For genuinely mixed values there is std::variant, listing the alternatives in advance. The R habit of returning a list of loosely related things becomes a small named struct, which is an improvement in both languages.

What replaces it is overloading — several functions with one name, chosen by the argument types — plus, in serious code, a small struct of options passed as one argument, which is the C++ answer to a function with eight named parameters. R's partial matching (describe(lo = TRUE)) has no counterpart either, and losing it is a mercy. The other change: an argument's type is checked, so describe(42) is a build error rather than a strange result.

Lazy evaluation is what makes R's non-standard evaluation possible — subset(data, score > 80) works because score > 80 arrives unevaluated and the function can inspect it. None of that transfers: a C++ function receives values, not expressions, and has no way to see the code that produced them. To defer work in C++ you pass a lambda and call it when you want it, which is explicit and considerably less magical.

R's condition system is richer than it first appears — warning, message, restarts and withCallingHandlers have no C++ equivalent, and neither does finally, whose job a destructor does instead. Going the other way, C++ exceptions cost real time when thrown and some codebases disable them entirely, so idiomatic modern C++ returns std::expected<T, E> for failures it expects and reserves exceptions for the genuinely exceptional.

This is why Rcpp is on thousands of CRAN packages while the raw .Call interface is on few. Two things worth noticing in six lines: NumericVector is R's actual vector rather than a copy of it, so passing a million elements costs nothing, and indexing it is zero-based even though the same vector is one-based in R — which is the single most common Rcpp bug.

clone() is how you restore R's semantics, and it should be the default unless you have measured that the copy matters and documented that the function mutates. The wider rule for designing an Rcpp boundary: keep it coarse — one call doing a lot of work rather than many small ones — because each crossing has overhead, and prefer Rcpp's own vector types over std::vector for anything large, since they avoid the conversion entirely.

The rough shape of the payoff, and it is worth being honest about both ends: a tight scalar loop typically runs 50 to 100 times faster, an already-vectorized operation runs about the same, and something dominated by memory allocation or by calls back into R may be slower. Profile with profvis first and rewrite the one function that dominates — the R programmer's advantage here is that the boundary is cheap enough to move exactly one function across and leave everything else alone.

That list is the answer to "why is my R loop slow", and it is also why the fix is usually vectorization rather than C++ — a vectorized call pays those costs once for the whole vector instead of once per element. Where C++ wins outright is the case vectorization cannot reach. It is worth knowing that R's own byte-compiler (on by default since R 3.4) removes some of this overhead, so the gap is smaller than it was, and still large.

The practical consequences run in both directions. Prefer atomic vectors over lists in R when the elements are all one type, for the same cache reasons a C++ programmer prefers vector<double> over vector<shared_ptr<double>>. And when designing an Rcpp interface, pass numeric and integer vectors rather than lists or data frames where you can, because those are the ones that cross for nothing.