C++.CodeCompared.To/Kotlin

println appends the newline and renders any value through toString, so it behaves like std::cout << … << std::endl without the operator chain. Semicolons are optional and idiomatic Kotlin omits them; the parser ends a statement at the newline unless the line is obviously incomplete. main returns Unit — Kotlin's void, except that it is a real type with one value — so there is no return 0, and a non-zero exit comes from kotlin.system.exitProcess.

That framing changes what matters. You are unlikely to rewrite a renderer in Kotlin, so the sections on the object model are there to stop your C++ intuitions misleading you when you read or write the layer above — and the JNI section at the end is the part you will actually use. If you are not shipping on Android or the JVM, this is a good language with little reason to reach for it, and Rust or Go answers more of a C++ programmer's questions. If you are, it is not really a choice.

Every class instance is heap-allocated and every variable holding one is a reference, so second = first aliases rather than copies and the C++ column prints 1 99 while the Kotlin column prints 99 99. There is no stack allocation you can request, no &, no pointer, and no way to embed one object inside another by value — a field holding a Point stores a reference to a separate heap object. The partial escape hatches are data class with copy() (explicit duplication, next section) and value class, which is limited to wrapping exactly one field.

A local Int and an IntArray element are machine integers. An Int in a generic container is a boxed java.lang.Integer — a heap object with a header — because JVM generics cannot hold primitives (the erasure section explains why). So List<Int> costs perhaps twenty times the memory of a std::vector<int> and loses all cache locality. The primitive-array types (IntArray, DoubleArray, …) exist exactly for this, and they are what you reach for in a hot path — which is also why they appear all over Android graphics APIs.

A String cannot hold null and a String? cannot be dereferenced without handling the null case — both are compile errors, not warnings, so the null-dereference bug is gone from Kotlin-only code. After if (text == null) return the compiler smart-casts the variable to the non-null type, so no cast is written. The operators are worth knowing: ?. short-circuits to null, ?: supplies a default (the "Elvis" operator), and !! asserts non-null and throws. The gap is the boundary: values arriving from Java or JNI are "platform types" the compiler cannot check, which is exactly where your C++ code hands things over.

use is an extension function on AutoCloseable that runs the block and calls close() in a finally — so the guarantee holds, and the obligation sits with every caller instead of with the type. That is the same trade Go, Zig and C# make. Note the two places C++ puts constructor work: init { } runs at construction, and the primary constructor parameters double as property declarations when marked val/var. Nothing in the language stops you forgetting use; static analysis and code review are what catch it.

The generated members are the ones you would otherwise write by hand: equals comparing fields, hashCode, a readable toString, and copy() with named parameters for changing one field. Because assignment still aliases, copy() is how you get a duplicate — explicit where C++'s is implicit, which is arguably clearer and certainly easier to forget. The component1/component2 functions are what make destructuring work, and they are positional, so reordering the fields of a data class silently changes what every destructuring site binds.

Marking a constructor parameter val or var makes it a property, with the backing field, getter and (for var) setter generated — so the class body is often empty. Turning a stored property into a computed one later changes no caller, which is the same benefit C# properties give and the reason the C++ habit of writing accessors defensively is unnecessary. Custom accessors go under the declaration as get()/set(value), and by lazy { … } gives a thread-safe compute-once property in one line.

The reasoning is that inheriting from a class not designed for it is how fragile base classes happen — so open is a deliberate act, and override is mandatory rather than the optional courtesy it is in C++. Combined with single inheritance (one superclass, any number of interfaces), this removes the diamond problem, virtual bases and slicing in one go. Note that abstract members are implicitly open, and that this default is genuinely annoying when you want to mock a class in a test, which is why Android projects commonly add the all-open compiler plugin.

: Greeter by inner generates a forwarding implementation of every interface method, and any method you write yourself wins. So the decorator pattern costs one clause rather than one method per interface member — and adding a method to the interface later does not break the decorator. There is no C++ equivalent short of a macro or a CRTP template. The same by keyword also does property delegation (by lazy, by observable, and the by viewModels() you will see throughout Android code).

A C++ template generates separate code per instantiation, so std::vector<int> stores real integers and knows its type at runtime. JVM generics are erased: List<Int> and List<String> are the same class, the type argument exists only for compile-time checking, and elements must be reference types — which is why List<Int> boxes. The practical consequences are that you cannot write is List<Int>, cannot create an array of T, and cannot overload on List<Int> versus List<String>. There is no runtime dispatch cost, but there is no specialization either.

Marking a function inline means the compiler pastes its body at each call site; reified then lets the type parameter be used as a real type inside — so Element::class, is Element and Element() all work. This is monomorphization, applied per function rather than per type. The limits: it only works on inline functions, so not on classes and not on virtual methods, and inlining a large function at many call sites grows the bytecode. It is what makes idioms like gson.fromJson<MyType>(text) possible on a platform that otherwise cannot see MyType.

List declares no mutating methods and MutableList extends it with them, so a function taking a List cannot modify it. What it does not get is a promise that nobody else will: the same object is reachable through a MutableList reference, and changes show through the read-only view. So it is a capability restriction on this reference rather than an immutability guarantee — closer to const than to Rust's borrow rules, and weaker than both because there is no const-ness to propagate into elements. For a real guarantee, copy with toList() or use the immutable collections library.

Kotlin's collection operators are eager: filter allocates a new list, then map allocates another, so a four-stage chain over a large list allocates four intermediate lists. A C++ ranges view allocates none. asSequence() switches to lazy evaluation and matches the ranges behavior. The rule of thumb is that eager is fine and often faster for small collections (no wrapper objects, better inlining) and sequences win once the collection is large or the chain is long — and for a C++ programmer used to views being free, the default is worth remembering. it is the implicit name of a single lambda parameter.

when has no fallthrough, so no break to forget, and cases can be values, comma-separated lists, ranges (in 4..10), types (is String), or arbitrary boolean conditions when the subject is omitted. As an expression it must be exhaustive, so else is required unless the compiler can prove coverage — which it can for enums and sealed classes, the subject of the next section. if is an expression too, so Kotlin has no ternary operator and does not need one.

After if (value is String) the compiler treats value as a String inside the branch, so no static_cast, no std::get, and no second chance to name the wrong type. The same narrowing applies after a null check (which is why the null-safety row needed no cast) and inside a when branch. The limitation worth knowing: smart casting requires the compiler to prove the value cannot change between the check and the use, so it does not apply to a mutable property that another thread could write — which is a reasonable restriction that occasionally forces a local copy.

Because every subclass must be declared in the same module, the compiler can enumerate them and reject a when that misses one — so adding a case is a compile error at every site rather than a silent fallthrough. That is the same guarantee Rust enums and Swift enums give, and it is the strongest argument for this shape over an open class hierarchy. Compared with std::variant: the cases are named and can carry different structured payloads, no std::visit is needed, and each case is a real type with its own methods — at the cost of a heap allocation per value, since these are still classes.

Because any parameter can be passed by name, a default in the middle can be skipped without repeating it, which is precisely what C++ defaults cannot do. Named arguments also make a call site self-documenting, so the boolean-trap call connect(host, 80, true) becomes connect(host, secure = true). One JVM detail worth knowing: default arguments compile to a synthetic method with a bitmask rather than to overloads, so the default lives in one place at runtime instead of being baked into every caller's object file — which means changing it does not require recompiling callers, unlike C++.

An extension function is not added to the class: it compiles to a static function taking the receiver as its first parameter, and the call syntax is sugar. That means it is resolved statically — an extension cannot be overridden, and if a real member with the same signature exists, the member always wins. So it is a syntactic convenience rather than the true retroactive conformance Swift and Rust offer. Most of Kotlin's standard library is extension functions on Java types, which is how Kotlin makes the JVM feel like a different language without changing it.

The language provides only suspend and the compiler transformation; everything else — async, launch, dispatchers, channels, flows — is kotlinx.coroutines. That is closer to C++'s position than to Go's, with the difference that Kotlin has one such library and everyone uses it. Structured concurrency means a scope waits for its children and cancellation propagates down, so leaking a coroutine takes effort. The cost is around a few hundred bytes per coroutine against ~8MB of stack per OS thread, which is why Android does all its I/O this way. Note this row needs the coroutines dependency, unlike everything else on the page.

The rules that cost people the most time: the symbol name encodes the full package path and a typo is a runtime failure, not a compile error; jstring is not a char* and needs GetStringUTFChars with a matching Release; local references have a limited table and leak if you create them in a loop without DeleteLocalRef; and the boundary crossing is expensive enough that the design rule is the usual one — cross rarely with a lot of work. Direct ByteBuffer is the standard way to share a buffer without copying. Modern alternatives worth knowing are the JNI generator in AndroidX and, on the JVM proper, Project Panama's FFM API.

Kotlin/Native compiles through LLVM to a real binary with no VM, and its C interop is a .def file describing headers rather than JNI's hand-written glue — considerably more pleasant than the previous row. What does not change is the object model: it still has tracing garbage collection, still has reference semantics, and still boxes generics, so everything earlier on this page applies. What you get is the multiplatform story — one Kotlin core targeting Android through the JVM and iOS through Native — which is the actual reason a C++ team with a shared cross-platform core might look at it.

Judged purely as a language Kotlin is a good one — null safety that is actually enforced, sealed classes with exhaustive matching, and less ceremony than almost anything else on the JVM. Judged as a destination for a C++ programmer it is the narrowest on the list, because its reach is the JVM and Android rather than systems work, and Rust or Go answers more of the questions that send a C++ developer looking. The case for reading this page is the boundary: if your engine ships inside an Android app, you will be reading and writing the layer above it, and knowing where your C++ intuitions stop applying is worth an afternoon.