C++.CodeCompared.To/C#

These are top-level statements: the compiler wraps the file in a generated class with a Main, so the ceremony still exists and you no longer type it. The exit code works as you would expect — falling off the end means zero, and return 3; sets three. Console.WriteLine appends the newline and formats whatever you hand it by calling ToString, so there is no stream-operator chain and no format string to get wrong; Console.Write is the version without the newline.

Because a .dll carries complete type metadata, referencing a library means pointing at the assembly — there is nothing to #include, no declaration to keep in sync with a definition, no include guards and no include graph to recompile. Two consequences worth planning for: startup pays JIT cost (mitigated by tiered compilation, and avoidable with Native AOT, which trades away reflection), and the metadata that makes this work also makes decompiling trivial, so shipped C# is far more readable than shipped C++.

A struct is a value type: it copies on assignment, lives inline (on the stack as a local, or embedded in its containing object), cannot be null, and compares by field. A class is a reference type: assignment copies the reference, the object is always on the heap, it can be null, and == compares identity by default. So the C++ column prints 1 1 and the C# column prints 1 99. The practical rule is that class is the default and struct is for small immutable value-like things — 16 bytes or so — because copying a large struct is exactly as expensive as it sounds.

Assigning a value type to object, or to an interface it implements, allocates a heap box and copies the value into it — silently, with nothing at the call site to warn you. In a hot loop this is the difference between zero allocations and millions, which is why it dominates C# performance advice in game development. Generics avoid it (they are reified, so List<int> genuinely stores ints), and the modern APIs are built to avoid it too. The rule to carry over: watch for a value type crossing into object, dynamic, or a non-generic interface.

The three differ in obligation: ref must be initialized by the caller and may be changed, out need not be initialized and must be assigned before the method returns, and in is a read-only reference — the closest thing to const T&, used to pass a large struct without copying. The part worth stealing is that the call site must repeat the keyword, so DoubleInPlace(ref reading) announces that the argument may change, which the equivalent C++ call does not. Note that reference types need none of this: they are already passed by reference.

A finalizer (~Transaction) exists and is almost always the wrong tool: it runs at an unpredictable time on a separate thread, may not run at all, and having one makes the object take two collections to reclaim. using is the real mechanism, and the difference from RAII is where the obligation sits — a C++ destructor is guaranteed by the type, while using is written by each caller, who can forget. The compensations are that the compiler warns when a disposable is not disposed and that using var (no braces needed) makes it a one-word habit.

Allocation is a pointer bump into a contiguous nursery, so it is genuinely faster than malloc; short-lived objects die in generation 0 and cost almost nothing to collect; and compaction means fragmentation does not exist. The prices: objects move, so a raw address is only valid while pinned (see the unsafe section), and collection pauses are longer than Go's because .NET tuned for throughput rather than pause time — server GC and background collection reduce but do not eliminate them. For a C++ programmer the mental shift is that allocation rate matters more than allocation count, and the thing to optimize is what survives generation 0.

Because card.Width is already a method call, turning a stored value into a computed one — or adding validation, or logging — changes no caller and requires no recompilation of dependents. That is why C# code exposes properties where C++ exposes get_x()/set_x(). Three modifiers to know: get; set; is read/write, get; init; allows assignment only in an object initializer (the closest thing to a const member you can still set at construction), and => declares an expression-bodied read-only property. The primary constructor on the class line is C# 12 and later.

The generated members are the ones every value-like type needs, and the one with no C++ equivalent is with: a non-destructive copy that changes named fields, which makes immutable-by-default designs practical. Note that a record is still a reference type — heap-allocated, nullable — that has merely had value semantics given to it, which is a distinction the previous section makes matter. record struct gives you a value type with the same generated members, and is the closer analogue of the C++ column here.

Two smaller differences matter daily. override is mandatory rather than the optional courtesy it is in C++, so the classic bug where a slightly-wrong signature silently declares a new method is a compile error. And object slicing cannot happen: a Shape variable holds a reference, never a sliced copy, so assigning a Square to it keeps the whole object. Methods are non-virtual by default exactly as in C++, and sealed is the counterpart of marking a class final. Multiple implementation inheritance is approximated by default interface methods, added in C# 8.

The tradeoff is the usual one for nominal typing: nothing satisfies an interface by accident, tooling can enumerate implementations, and the runtime can dispatch on it — but you cannot make a third-party type satisfy an interface it does not declare, which needs an adapter class. Note that C# also has generics with constraints, so the structural style is available: void Introduce<T>(T speaker) where T : ISpeaking gets monomorphized dispatch instead of an interface call, at the cost of still requiring the declaration. The prefix I is a universal convention, not a rule.

"Reified" means List<int> genuinely stores ints with no boxing, and typeof(T) works at runtime — unlike Java, where the type is erased. Value-type instantiations are specialized like a template; reference-type ones share one compiled body. What you give up against C++ is the metaprogramming: no specialization, no non-type parameters (so no std::array<int, 3>), no variadic type parameters, and the body may only use what the constraint proves. C# 11 added INumber<T>, which finally makes generic arithmetic expressible — for years it simply was not.

A C# array is a heap object carrying its own length, so raw.Length is always right and never depends on whether the array has decayed to a pointer — the sizeof(raw)/sizeof(raw[0]) idiom and its failure mode simply do not exist. Every index is bounds-checked, throwing IndexOutOfRangeException rather than being undefined; the JIT elides most of those checks in loops it can prove safe. Note Dictionary's indexer throws on a missing key rather than inserting like std::unordered_map::operator[], which is the safer default, and TryGetValue is the comma-ok form.

Both are lazy, and both compose. The differences are in cost and reach: a ranges pipeline monomorphizes and typically compiles to the same code as a hand-written loop, while LINQ allocates an iterator object per stage and dispatches through delegates, so it is measurably slower — enough that Unity code often avoids it in per-frame paths. In exchange LINQ reaches further: the same query syntax runs against a database through IQueryable, where the expression tree is translated to SQL rather than executed. There is no C++ equivalent of that.

Everything throwable derives from Exception, so catch (Exception) genuinely catches everything — where C++ permits throw 42, making catch (const std::exception&) incomplete and catch (...) give you no object. finally exists because there are no destructors to carry cleanup, and it is what using compiles into. And when is an exception filter that decides whether to catch without unwinding first, so the original stack is preserved for a crash dump — genuinely useful, and with no C++ equivalent. Note that C# has no noexcept and no exception specifications; that experiment was studied and deliberately not repeated.

With nullable reference types enabled, string means "should not be null" and string? means "may be", and the compiler performs flow analysis — after if (text is null) return; the variable is narrowed to non-null. The crucial caveat is that this is warnings, not enforcement: the annotations are erased at runtime, nothing stops a library compiled without them from handing you a null, and ! suppresses the warning outright. So it is closer to a linter than to Rust's Option. The operators are worth adopting mentally: ?. short-circuits, ?? supplies a default, ??= assigns only if null.

Multicast is the part with no C++ counterpart — += chains handlers onto a single delegate and invoking it calls each in turn, which is why the observer pattern needs no library here. event builds on that with encapsulation: outside code may += and -= but cannot invoke or clear it. A delegate also carries its receiver, so instance.Method is a valid delegate with the object bound in, replacing std::bind and pointer-to-member syntax. The cost is an allocation per delegate and an indirect call, so per-frame game code prefers passing a struct constrained to an interface.

The compiler rewrites captured locals into fields of a generated heap class, so the variable outlives the scope it was declared in and the closure and the enclosing method genuinely share it — which is why running is 7 after the calls. A C++ lambda capturing by reference and outliving the scope is undefined behavior, and [&] makes that one character wide. The costs here are an allocation for the closure and the fact that you cannot opt out of sharing: to capture a snapshot you assign to a fresh local first. C# 9 added static lambdas, which refuse to capture at all — useful for proving a hot path allocates nothing.

A switch expression produces a value rather than executing statements, so it fits in an initializer and needs no mutable variable. The patterns compose: type patterns bind (int number), relational patterns compare (> 100), and/or/not combine them, property patterns destructure ({ Length: > 3 }), and list patterns match sequences. Exhaustiveness is checked only for types the compiler can enumerate — enums and closed hierarchies — so a warning rather than the hard error Rust gives. The trailing _ is the discard arm.

The compiler rewrites an async method into a state machine that suspends at each await, releasing the thread rather than blocking it, so a server handles thousands of concurrent operations on a small thread pool. C++20 gives you co_await and the customization points and no std::task, no scheduler and no async standard library, so using it means adopting asio or cppcoro and writing promise types. The traps in C# are worth naming: async void cannot be awaited and its exceptions crash the process (use it only for event handlers), and calling .Result on a Task deadlocks in contexts with a synchronization context.

Span<T> is a ref struct, a type the compiler forbids from being boxed, stored in a class field, captured by a lambda, or held across an await — all the ways it could outlive its target. So the dangling-span bug that compiles in C++ does not compile here. It views arrays, strings, stackalloc memory and native pointers uniformly, which is why the modern .NET APIs are written against it: parsing, formatting and I/O now run with zero allocations. If you arrived expecting C# to be unusable for hot paths, this and the next row are the reasons that stopped being true around .NET Core 2.1.

The compacting collector moves objects, so taking a pointer into managed memory requires fixed, which pins the object for the duration of the block. Outside it the address may be stale by the next statement — a failure mode with no C++ analogue, since nothing relocates your objects there. Pinning also works against the collector by fragmenting the heap, so the guidance is to pin narrowly and briefly, and to prefer Span<T>, which gets most of the benefit with none of the pinning. Unmanaged memory from NativeMemory.Alloc never moves and needs no pinning at all.

The rules that matter in practice: blittable types (integers, floats, and structs made only of them) cross the boundary with no conversion and no cost, while strings, arrays and anything with a managed layout are marshalled, which allocates and copies. The boundary is a real call and a real transition, so the design rule matches every other FFI — cross rarely with a lot of work, not often with a little. [StructLayout(LayoutKind.Sequential)] is required to make a struct match a C one, since the runtime is otherwise free to reorder fields. Unreal's C++/Blueprint split and Unity's C#-over-C++ engine are both this boundary.

The trade is narrower than it was. .NET Core closed most of the throughput gap, Span<T> made allocation-free hot paths ordinary, and Native AOT removes the runtime and the JIT for startup-sensitive work. What remains genuinely C++'s is deterministic destruction, hard latency bounds, direct hardware access, and the metaprogramming that makes zero-overhead abstraction possible. Notice that both major game engines drew the line in the same place, and that is a reasonable default: keep C++ where the microseconds and the memory layout matter, and take C# for everything built on top of it.