Python.CodeCompared.To/C++

The C++ file is not executed — it is translated, and the thing that runs afterwards is a machine-code file that no longer mentions C++. That is the difference the whole page turns on: everything the C++ compiler is going to check, it checks before the program exists, and everything it cannot check it does not check at all. std::endl writes a newline and flushes; \n alone writes the newline without the flush and is what you want in a loop.

This is the trade in one row, and it cuts both ways: C++ finds the typo, and C++ also makes you wait for the compiler every time you want to see anything at all. A Python developer coming to C++ usually underestimates how much of their working rhythm was "run it and look" — a habit that costs a second in Python and thirty in a real C++ build.

The if __name__ == "__main__" guard has no C++ counterpart because the problem it solves does not exist — including a header cannot print anything, register anything or open a connection, because a header is declarations. The nearest thing to import-time work is a global object whose constructor runs before main, and it is widely considered a mistake to rely on: the order across files is unspecified, a fact experienced C++ programmers refer to as the static initialization order fiasco.

In Python = binds a name; in C++ = copies a value. So the Python list grows to four elements because there was only ever one list, and the C++ vector does not because there were always two. Nothing about the syntax says so — this is why a Python programmer reading C++ consistently under-counts how much work the program is doing, and why a C++ programmer reading Python consistently over-counts how safe it is to hand a list to a function.

The defaults are mirror images: Python aliases unless you say list(...) or copy.deepcopy, C++ copies unless you say &. A C++ reference must be bound when it is created and can never be re-seated afterwards, so it is closer to a permanent second name than to a Python variable — you cannot point it somewhere else later.

A C++ signature is a contract about copying, which is why you will see const std::vector<int>& everywhere in real code — it means "I need to read this, I will not copy it, and I will not change it". Passing a large container by value is a real and common performance bug, and it is invisible at the call site: process(data) looks identical either way.

Note what happened to the third case. In Python third = first makes third is first true, and in C++ that is only true because the ampersand was written — without it third would be a copy sitting at a different address. Also note that == on a C++ container compares elements, exactly as Python does; it is == on a pointer that compares addresses, which is the trap on the other side.

Python answers "there is no answer" with None, which any function may return from any branch and which the caller may forget to check. C++ makes the absence part of the return type, so a caller who forgets does not compile — found + 1 is an error until the optional is unwrapped. nullptr still exists and still means an empty pointer, but returning one to signal "not found" is the older style and reads as a smell in new code.

auto is not Python's dynamism arriving late — it asks the compiler to write the type down for you, and the type is still fixed and still checked. Note that bool printed as 1, not true: streaming a bool gives you the integer unless you ask for std::boolalpha. This is the first of many places where C++ shows you the machine and Python shows you the idea.

🚨 The two failure modes are different and the second one is the dangerous one. Unsigned overflow wraps, which is defined, surprising and at least predictable. Signed overflow is undefined behavior: the compiler is entitled to assume it cannot happen, so a loop guarded by if (index + 1 < index) may be deleted entirely as dead code. If you have written Python for years, the habit of trusting an integer to just be a number is the single most expensive one to carry across.

Python floors (-7 // 2 is -4) and C++ truncates toward zero (-7 / 2 is -3), and the remainders follow: Python's % takes the sign of the divisor, C++'s takes the sign of the dividend. Any code that indexes a ring buffer or bucket by value % size with possibly-negative values changes behavior when ported, silently and only for some inputs. The other half of the row is that / on two C++ integers is integer division — 7 / 2 is 3, not 3.5 — so a stray integer literal quietly discards your fractional part.

This is the row that explains why C++ people distrust annotations. In Python a hint is documentation that a separate tool may or may not be pointed at; in C++ the signature is the only thing the call site is matched against, and a mismatch is not a warning but the absence of a program. The upside is fewer four-in-the-morning surprises; the cost is that generic code needs real machinery, which is what the Templates section is about.

The missing method is the point: C++ keeps a small string class and a large algorithm library, so anything shaped like "do this to every element" lives outside the type. std::ranges::transform writing into shouted.begin() is the idiom, and it is deliberately explicit about which buffer receives the result. What C++ does not have here is a mutable-versus-immutable distinction — a std::string can be modified in place, so there is no equivalent of Python building a new string for every operation.

The difference is that C++ cannot interpolate a variable by name: the braces are empty or numbered and the values come afterwards, because the format string is parsed at compile time and there is no way to look a local variable up by its spelling. That compile-time parsing is a genuine gain — a mismatched placeholder is a build error rather than a run-time exception. std::print("…", args) from <print> is the shorter spelling where your library has it.

A Python str is a sequence of code points and the encoding is a separate concern handled at the edges. A std::string is a sequence of char, which is to say bytes, and it has no idea what encoding they are in — indexing, slicing and length are all byte operations. Any Python code that iterates characters, truncates to a width or reverses a string has to be rethought rather than translated, and this is the most common source of mojibake in ported code.

This is the row that changes how much code you expect to write. C++ standardizes containers and algorithms, not conveniences, so a one-liner that exists in every scripting language is assembled from parts here — and every C++ codebase of any size has its own split in some utility header. std::views::split from C++20 does exist and is more elegant, but converting its pieces back into strings is verbose enough that most code still writes the loop.

Two habits to unlearn. There is no negative indexing, so values[-1] does not mean the last element — it reads memory before the vector and is undefined behavior; use .back(). And values[10] on a three-element vector does not raise IndexError, it simply reads whatever is there; .at(10) is the checked version that throws. A Python list of mixed types has no direct equivalent at all — the nearest thing is std::vector<std::variant<…>>, with the alternatives listed in advance.

🚨 The trap is operator[]. Looking up a missing key with square brackets does not raise KeyError — it inserts the key with a value-initialized value and hands it back, so a read-only-looking loop can grow the map. Use .contains(key) to ask, .at(key) to read with a throw on absence, and .find(key) when you want the answer and the value in one lookup. Also note that Python dictionaries preserve insertion order and neither C++ map does: unordered_map has no order at all, and map is sorted by key.

Where Python reaches for an anonymous tuple, C++ usually declares a small struct — it costs three lines and buys named fields, so the call site says result.remainder instead of result[1]. std::tuple exists and matches Python more literally, but reading it back needs std::get<1>(point) with the index inside angle brackets, because the index has to be known at compile time to know the type it returns.

So the two programs disagree about the last line, and the disagreement is the lesson: a Python slice is a new list, a span is a window. That makes spans free and makes them dangerous — the span is only valid while the vector it points into is alive and has not reallocated, and push_back during a span's lifetime can leave it pointing at freed memory. If you want Python's behavior, construct a new vector from the two iterators.

The set operations Python spells with operators — |, &, - for union, intersection and difference — are free functions in <algorithm> (std::set_union and friends) that write into an output iterator, and they require sorted input, which is one reason std::set earns its keep. There is no frozenset; a const std::set is the same idea.

Write for (const auto& value : things) rather than for (auto value : things) when the elements are anything bigger than a number — the second form copies every element as it goes, which is invisible, legal and a common source of a program being mysteriously slow. There is no range object to pass around; std::views::iota(0, 3) is the nearest equivalent.

C++23 does add std::views::enumerate and std::views::zip, which read almost exactly like the Python. They are deliberately not used here because they are not yet in every shipping standard library — this page's own local toolchain has neither, which is the kind of gap that decides what a real codebase can use. When your compiler and library both have them, prefer them: for (auto [index, name] : std::views::enumerate(names)).

The important difference is that the C++ version is lazy and produces no container: nothing is computed until the loop pulls values through, and squares_of_evens is a recipe rather than a vector. That makes it closer to a Python generator expression than to a list comprehension. Add | std::ranges::to<std::vector>() when you actually want the list.

C++23 defines std::generator, which is a real coroutine and reads very much like the Python — co_yield value * value inside the function and a range-based for at the call site. It is not used here because libc++ does not yet ship it, and that is the practical situation for a lot of C++23: the language feature landed years before the library support you need to use it. The callback form has a genuine advantage, though — it does not allocate a coroutine frame.

Overload resolution is doing real work here, and it is worth knowing it can surprise you: describe("widget", true) matches the two-parameter overload, but had the second overload not existed, true would have converted to int and printed 1 x widget without a word of complaint. Implicit conversions between arithmetic types make overload sets subtler than they look. Python's single-function-with-keywords approach has no equivalent trap, which is a real advantage of the dynamic side.

Python only has the second behavior, which is why the late-binding closure surprise exists — a lambda made inside a loop sees the loop variable's final value. C++ lets you say which you meant, and the copying form is the safer default because a captured reference outliving its variable is a dangling reference. [=] and [&] capture everything used, by copy and by reference respectively; the second is the one to be careful with when the lambda is stored rather than called immediately.

The mechanism is completely different even though the call sites match. Python collects the arguments into a tuple at run time and loops over it; C++ generates a separate function for each combination of argument types it sees, with the additions written out. That is why the second call returns a double without anything being said about types, and why a call with an argument that cannot be added is a compile error rather than a TypeError. There is no **kwargs equivalent at all.

This matters because older C++ advice — take an output parameter by reference, return an error code — is still all over the internet and is no longer the right default. Write the signature that says what the function means. reserve is worth the line when you know the size: a vector that grows by push_back reallocates and copies its contents several times on the way, which is the kind of cost Python's list also pays but nobody profiles.

There is no self parameter because the object is passed invisibly, and members are simply in scope inside a method. The bigger change is private: it is enforced by the compiler rather than signalled by an underscore, so code outside the class cannot touch value at all. Everything in a class is private until you say otherwise, which is the only difference between class and struct in C++.

The whole family of Python techniques that depend on adding to an object later has no C++ equivalent: no monkey patching, no setattr, no mixin applied at run time, no mock that replaces one method on one instance. In exchange, a member access compiles to an offset from a pointer rather than a dictionary lookup, and a misspelled member is a build error. The const after describe() is a promise the method does not modify the object, and the compiler holds you to it.

Python resolves every method call by looking in the instance's type at the moment of the call, so overriding always works. C++ resolves non-virtual calls at compile time from the declared type of the expression, so a base class has to opt in to being overridden. override on the derived method is not required but should always be written: it makes the compiler check that you really are overriding something, which catches a changed signature in the base class. The virtual destructor is the other half — deleting a Square through a Shape* without it is undefined behavior.

The correspondence is close: __add__ is operator+, __eq__ is operator==, __len__ has no equivalent because size is a method. Two things Python has no need of: explicit on the constructor, which stops Money being created accidentally from a bare integer in a function call, and the fact that you may overload operators for types you did not write — the << above extends std::ostream without touching it, which is a kind of open-classes power C++ does have.

This is a small syntactic loss and a real design gain: in C++ you can always tell by looking whether rectangle.area is a stored field or arbitrary code, and in Python you cannot. The consequence for a library author is the opposite of Python's advice — you cannot start with a public field and quietly turn it into a property later, because every call site would have to gain parentheses, so C++ codebases tend to write the accessor from the beginning.

This is duck typing moved to compile time, and the duck test is the same one: the template works for any type that supports > and copying. The difference is when you find out. Python tells you at the moment the comparison happens, possibly in production; C++ tells you at build time, in an error message that is famously enormous because it explains the failure in terms of the instantiated types. Concepts, in the next row, exist to make that message readable.

The two ideas line up almost exactly, and the difference is enforcement: a Protocol is checked by mypy if you run it, while a concept is checked by the compiler always. The practical payoff is the error message. Without the concept, passing a type with no < produces pages of instantiation backtrace; with it, the compiler says the constraint was not satisfied and names it. This is the single biggest quality-of-life change in modern C++ for anyone writing generic code.

There is no Python analog, and this is one of the genuinely different capabilities rather than a syntax difference: lookup tables, parsers for format strings and entire unit systems get evaluated away, leaving constants in the binary. Modern C++ has pushed this a long way — most of the standard library is usable in a constexpr context, including std::vector and std::string. The failure mode to know about is that a static_assert failure is a compile error with no stack trace, because there is no stack.

CPython's reference counting usually gets you the same order, which is why this row looks like agreement — but it is a promise Python does not make. A reference cycle, an exception holding a traceback, or simply a different interpreter defers __del__ indefinitely, which is why Python has with statements for anything that must be released on time. C++ has no with because the destructor is the mechanism, and it fires even when an exception unwinds through the function.

This pattern has a name, RAII, and it is the organizing idea of the whole language: a file handle, a lock, a database transaction and an allocation are all objects whose destructors release what they hold. It is why C++ does not need finally, why it does not need with, and why "who closes this" is answered by the type rather than by the caller remembering. A Python programmer's instinct to write cleanup at the end of a function is the habit to drop.

std::move does not move anything; it is a cast that says "you may take this from me", and afterwards the source is empty and must not be used except to reassign or destroy it. Notice what happened without a garbage collector: the resource is freed exactly once, at the end of main, with no reference counting at run time. This is the closest thing C++ has to Rust's ownership, arrived at from the other direction and without a borrow checker.

Understanding this makes the C++ memory model feel much less alien: you already live in a reference-counted world, you simply never had to write it down. The two also share the same weakness — a cycle of shared_ptrs never reaches zero and leaks, exactly as a CPython cycle would if the cycle collector did not exist. C++ has no cycle collector, so it has std::weak_ptr, which you break the cycle with by hand. The other half of the comparison is cost: a shared pointer's count is atomic, so copying one is more expensive than copying a raw pointer, which is why unique_ptr is the default choice and shared_ptr is for genuinely shared ownership.

This is the bug class with no Python counterpart, and it is why the example re-reads values[0] instead of using first after the push. A Python name cannot dangle: it holds the object, and the object moves nowhere. In C++ the rule to internalize is that anything derived from a container's storage — references, pointers, iterators, spans — has a lifetime tied to that storage, and the operations that end it are documented per container. std::list and std::map do not invalidate on insertion; std::vector does.

The mechanics line up, but the culture does not. Python uses exceptions for ordinary control flow — StopIteration ends every loop — while C++ reserves them for genuinely exceptional conditions, partly because the cost is paid when one is thrown and partly because whole domains (games, embedded, some finance) compile with exceptions disabled entirely. There is no except: catching everything by accident; catch (...) exists and is deliberately ugly.

This is why the language never grew a finally clause, and it is a better answer than Python's in one specific way: the cleanup is written once, in the type, rather than at every place the resource is used. A function that acquires three things does not need three nested try blocks. The obligation it puts on you is real, though — any type that holds something must have a correct destructor, and writing one badly is how leaks and double-frees happen.

C++23 added this because exceptions are not always available or wanted, and the older alternative — return a code and write the result through a pointer — loses the type. Python has no equivalent in the standard library, and the tuple-of-value-and-error convention shown on the left is borrowed from Go rather than idiomatic. What the C++ version buys is that the caller cannot reach the value without acknowledging the error case: *result on a failed expected is undefined, so the if is not optional in practice.

The one C++ specific worth knowing is static_assert, which is checked at compile time and cannot be turned off — it is the right tool for anything about types or sizes rather than values. The shared rule matters more: never put work with side effects inside an assertion, because a release build will not run it. This bites harder in C++ than in Python, since -DNDEBUG is the default in most release configurations while python3 -O is rarely used.

This is usually the reason a Python programmer is reading this page at all. The global interpreter lock means CPython threads interleave rather than overlap for anything CPU-bound, so the standard advice is multiprocessing and its copying costs. C++ threads are operating-system threads with shared memory and no interpreter lock — which is the speedup and also the danger, because a data race in C++ is undefined behavior rather than a wrong number. Python 3.13 introduced a free-threaded build that removes the lock; it is opt-in and still maturing.

C++20 added coroutines with co_await, which are much closer to async/await in spirit — but the standard library ships no event loop to drive them, so every practical use goes through a third-party framework such as Asio or cppcoro. That is the honest state of the art: the language feature exists, the batteries do not, and most production C++ concurrency is still threads, futures and a thread pool somebody wrote.

This is the shape of every fast Python package you use. The cost that is easy to miss is the conversion: pybind11/stl.h copies the list into a vector on the way in, so a function called in a tight loop over a large list can spend more time converting than computing — which is why NumPy-facing bindings take a buffer or an py::array_t instead, and touch the same memory the array already owns.

🚨 The rule that goes with it is absolute: touch nothing Python-related while the lock is released — no py::object, no reference counting, no exception into Python. Doing so is not an error message but a crash or silent corruption, and it is the most common serious bug in hand-written extensions. Note that the release is an object whose destructor re-acquires, so an early return or a thrown exception restores the lock correctly; that is RAII doing the same job it does everywhere else in the language.

The trade against pybind11 is worth stating plainly. ctypes needs no build-time dependency on Python at all and works with a library you did not compile — but every type is declared twice, in two languages, with nothing checking that the two declarations agree. pybind11 generates the boundary from the real C++ signature, so it cannot drift, at the cost of compiling against the Python headers of the exact interpreter you will run on. cffi sits between them, and Cython is a fourth option that compiles a Python-like language down to the same C API.

The buffer protocol is the reason the scientific Python stack works at all — NumPy, PyTorch, Polars and Arrow all agree on a way to describe a block of memory, so a C++ library can read what a Python library allocated without a copy. Two things to be careful with: check buffer.strides rather than assuming the array is contiguous, since a slice of an array usually is not, and hold the interpreter lock while the array object could be resized or freed under you.

Two practical consequences. There is no namespacing by file — everything included lands in the same translation unit, which is why the standard library lives in the std namespace and why using namespace std; is discouraged in anything but a toy. And there is no equivalent of Python's single execution and cache, so the same header is re-parsed for every source file that includes it. C++20 modules fix this properly and are still rolling out unevenly across compilers and build systems.

This split is the whole reason headers exist: the header holds declarations so every file can be compiled independently, and the linker matches them to definitions afterwards. It also explains the two error messages a newcomer confuses — "undeclared identifier" comes from the compiler and means it never saw the promise, while "undefined reference" comes from the linker and means the promise was never kept. Python has no such distinction because a function body is not looked at until it runs.

CMake is the closest thing to a standard, and it is a build system rather than a package manager; vcpkg and Conan sit on top of it and are both in wide use without either winning. Expect to spend real time on this, expect the first build of a new dependency to fail, and treat a library that ships a working CMakeLists.txt as a meaningful sign of quality. The one genuine advantage: because you build from source with your own flags, you can debug into your dependencies, which is a thing a wheel does not let you do.