C#.CodeCompared.To/C++

That distinction is worth having straight from the first row. A using directive tells C# where to look for names that are already compiled into an assembly; #include copies text. So a C++ header is not a namespace, does not have to correspond to one, and re-parsing it for every source file is why C++ builds are slow. C++20 modules fix this and are rolling out unevenly across compilers and build systems.

Two consequences a C# developer feels immediately. Everything that depends on run-time type information — serializers that read your properties, dependency injection containers that construct by type, mocking frameworks — has no C++ equivalent, and the replacement is code generation at build time or explicit registration you write. In return: startup in microseconds, no warmup, no collector pause, and a binary that does not need a runtime installed. NativeAOT is .NET moving toward the same trade, and it loses reflection for the same reason.

So the intuition to carry over is: treat every C++ type as if it were a C# struct, and reach for a pointer or a reference when you want C# class behavior. There is no boxing, because there is nothing to box into — and no ref struct restriction either, since any type can live on the stack. Where C# ties the default to the kind of type — a struct is copied, a class is shared, and ref, in and out are the exceptions you write — C++ gives you one kind of type and has you choose the convention at each parameter, which is the next row.

🚨 The difference that bites is that C++ does not mark the call site. C# makes you write Increment(ref counter), so a reader can see the variable may change; in C++ increment(counter) looks identical to a by-value call, and only the signature says otherwise. That is why const& is written everywhere in good C++ — it is the only way a reader can tell a function will not modify what it was handed. There is no ref return ceremony either: returning int& just works, and dangling is your problem.

That is the reverse of the C# situation, where a struct copy is shallow and a contained reference is shared. It is also the reason C++ has the rule of five: a class that manages a resource must say what copying, moving and destroying mean (copy constructor, copy assignment, move constructor, move assignment, destructor), or the generated versions will do the wrong thing. The modern answer is the rule of zero — hold members that manage themselves, such as std::vector and std::unique_ptr, and write none of the five.

🚨 The difference is who is responsible. C# puts the obligation on every call site: forget the using and Dispose never runs — without a word from the compiler, since the analyzer rule that catches it is not on by default — which is why IDisposable has to propagate up through every type that holds one. C++ puts it in the type, so a caller cannot forget. This is RAII, it is the organizing idea of the language, and it is the thing most worth internalizing — files, locks, transactions and allocations are all objects whose destructors release what they hold.

The rule of thumb is unique_ptr by default and shared_ptr only when ownership is genuinely shared, because the shared count is atomic and copying one is not free. Note that shared_ptr has the weakness .NET's collector does not: a cycle never reaches zero and leaks, which is what weak_ptr is for. A C# developer's instinct — that any reference may be kept anywhere — is exactly what these types exist to stop you doing accidentally.

What replaces it is nothing: write a destructor and stop. The obligation that comes with that is real though — a destructor must not throw (an exception escaping one during stack unwinding terminates the program), and a base class you delete through needs a virtual destructor. Those two rules are the whole of what a C# developer has to learn here, and they replace considerably more ceremony than they add.

🚨 There is no checked in C++ and no OverflowException: signed overflow is undefined behavior, which means the compiler may assume it does not occur and optimize accordingly — a guard written as if (value + 1 < value) can be deleted as provably false. Use -fsanitize=undefined during development, and __builtin_add_overflow or C++26's checked arithmetic when it matters. The other difference is that int and long have no fixed size in C++, so <cstdint> is what you write when the width matters.

Where they part company is reference types. C# added nullable reference annotations, so string? versus string is checked by the compiler; C++ has no such thing, and a raw pointer may always be null with nothing tracking it. So std::optional is used where C# uses int?, and for reference-like cases the convention is a reference (which cannot be null) when the value is required, and a pointer when it is not. value_or(0) is ?? 0, and there is no ?. operator.

🚨 Plain auto strips references and const, so auto item = collection[0] makes a copy, and for (auto item : collection) copies every element as it goes — invisible, legal, and a common reason a loop is mysteriously slow. Write const auto& when you mean to observe and auto& when you mean to modify. C# has no equivalent trap because foreach over a reference-type collection never copies the objects.

So size() counts bytes where Length counts UTF-16 code units — for "héllo" that is 6 against 5. Here Length happens to equal the number of characters, but not in general: an emoji such as 😀 is two UTF-16 code units, and a flag is four. Indexing, substrings and reversal are all byte operations, so any C# code that manipulates text by position has to be rethought rather than translated. There is also no StringBuilder, because it is unnecessary: appending to a std::string amortizes, exactly as List<T> does. std::format borrowed its mini-language from Python, so {:.2f} works but $"{name}" interpolation does not exist.

🚨 Two traps. counts["fig"] on a missing key does not throw KeyNotFoundException — it inserts a default-constructed value and returns it, so a read-only-looking loop can grow the map; use .at() to throw or .contains() to ask. And values[10] on a three-element vector is undefined behavior rather than an ArgumentOutOfRangeException; .at(10) is the checked version. There is no ^1 index-from-end operator, so the last element is .back().

The pipe reads left to right the way method chaining does, so the shape transfers directly. What does not transfer is the breadth — there is no GroupBy, no OrderBy in views (sorting needs a container), no ToDictionary, and the fold operations live in <numeric> as std::accumulate or C++23's std::ranges::fold_left. | std::ranges::to<std::vector>() is ToList(). And there is no query syntax and no IQueryable, so nothing translates a range pipeline into SQL.

The rules are per container and worth learning: std::vector invalidates everything on reallocation and everything after the point of an insert or erase; std::list and std::map invalidate only what you erased. erase returns the next valid iterator, which is why the removal idiom is it = values.erase(it). C++20 added std::erase_if(values, predicate), which is RemoveAll and is what you should reach for first.

Three C++ specifics. A base class you delete through must have a virtual destructor, or the derived part is never destroyed — undefined behavior, and the compiler does not warn by default. override is optional here, while C# needs it to override at all — leave it off there and the method hides the base one, with a warning — and it should always be written, because it turns a mistyped signature into a compile error. And report takes const Shape& rather than Shape: passing by value would slice the object down to its base, copying only the Shape part and calling the base area() — a bug C# cannot have, because class instances are never copied by value.

C++ allows multiple inheritance of implementation, not merely of interface, which is more power and a known hazard: inheriting the same base twice gives you two copies of its state unless you use virtual inheritance, the diamond problem C# avoided by forbidding more than one base class. C# default interface methods carry no state, and when two of them meet in a diamond the compiler refuses the class until it picks one. Two things worth knowing: an interface with no data costs a vtable pointer per object, and templates plus concepts give you compile-time polymorphism with no virtual call at all, which is often the better tool where C# would use a generic constrained by an interface.

The gain from losing properties is that you can always tell by looking whether money.dollars is a field or arbitrary code. The consequence for a library author is the one C# advice already warns about — there, turning a public field into a property breaks compiled callers and any caller that passes it by ref — except that C++ has no property to turn it into, so C++ code writes the accessor from the start. explicit has no C# equivalent and is worth adopting — without it, a single-argument constructor makes an implicit conversion the compiler will apply silently.

Because it is separately generated, a template can do things a C# generic cannot: specialize for a particular type, compute with the type, take non-type parameters (template <int Size>), and inline everything so a comparison costs nothing. The prices are compile time, code size, and error messages that describe a failure in terms of instantiated types — which is what C++20 concepts exist to fix, and which map almost exactly onto C#'s where clauses.

That is the practical difference. A C# constraint names what a type is — a base type, an interface, new(), struct, class, notnull or unmanaged — never an expression that must compile, so "any type supporting +" is spelled by naming an interface that declares the operator, such as IAdditionOperators<T, T, T> or INumber<T>, both added only recently. A concept says it directly. The payoff a C++ developer notices first is the error message: a violated concept names the constraint instead of producing pages of instantiation backtrace.

The cultural difference is larger than the syntactic one. .NET throws freely and an exception carries a stack trace; C++ exceptions carry no trace at all, cost more when thrown, and whole domains — games, embedded, some finance — compile with -fno-exceptions, which means a library that throws cannot be used there. So idiomatic modern C++ returns std::expected<T, E> for failures that are expected, and reserves exceptions for the genuinely exceptional. There is no when filter and no catch by exception property.

That is the improvement over TryParse: a bool can say something went wrong but not what. .NET APIs that need to explain a failure either throw or, like Base64.DecodeFromUtf8, return a status value such as OperationStatus.InvalidData. C++23's version composes too — and_then and transform chain operations that may fail without nesting if statements. The caller cannot reach the value without acknowledging the error case, since dereferencing a failed expected is undefined, so the check is not optional in practice.

The difference is what enforces the safety. C# makes Span<T> a ref struct so the compiler forbids storing one on the heap, capturing it in a lambda or using it across an await. C++ has no such rule: a std::span may be stored anywhere, and it dangles the moment the container behind it reallocates or dies. So the C# habits transfer, but the guardrail does not — the discipline must be yours.

Which is why a C# developer who has used Span<T>, stackalloc and unsafe arrives better prepared than almost anyone: the mental model is already right, and what changes is that the guardrails are gone rather than that the ideas are new. The habits worth keeping are the ones fixed taught — know how long a pointer is valid, and never let one outlive what it points at.

The rule that follows is the one that decides how an interop layer is designed: only C types cross the boundary. No std::vector, no std::string, no class with virtual methods, no exceptions — a C++ exception crossing into managed code is undefined. So a C++ library gets a thin C façade of functions taking pointers, lengths and opaque handles, which is exactly what every well-behaved native library ships. Keep the boundary coarse, because each crossing costs far more than a managed call.

The practical checklist for a real interop layer: keep the boundary small and coarse, copy data across rather than holding pointers into the managed heap, pair every allocating function with a freeing one, return status codes rather than throwing, and test the native library on its own with a sanitizer build. A crash inside a .NET process is far harder to diagnose than the same crash in a small C++ test program — which is the single most useful thing to know before starting.

CMake is the closest thing to a standard and is a build system rather than a package manager; vcpkg and Conan sit on top of it, both in wide use with neither winning. Budget real time for this, expect the first build of a new dependency to fail, and treat a library shipping a working CMakeLists.txt as a signal of quality. The genuine compensation is that you build from source with your own flags, so you can step into a dependency in the debugger — which a NuGet package does not let you do.