GDScript.CodeCompared.To/C++

That difference is the whole shape of the page. A GDScript file is a class the engine loads and calls; a C++ file is a translation unit a compiler turns into machine code, and something else has to decide when it runs.

There is no format string to keep in step with a list, so a mismatched placeholder cannot happen. Inside the engine you would use Godot's own UtilityFunctions::print instead, which behaves like the print you know.

Because the compiler cannot see your layout, a misleadingly indented line is a readability bug rather than a behavior change — the opposite of the risk you are used to. Every statement also ends in a semicolon, which is the most common thing to forget on the first day.

Godot's own C++ has a Variant class much closer to GDScript's, because the engine needs one to talk to scripts. In ordinary C++ this shape is rare — the language expects you to know what a name holds.

Note the explicit std::string — a bare "boss" makes auto deduce a C-style character pointer, not a string object. That is a distinction GDScript never asks you to make, and it is the first place auto surprises people.

Writing the comparison out is the habit worth forming. It costs a few characters and removes an entire category of bug that the compiler will not warn you about.

The fixed-width names from <cstdint> say exactly how many bits you get, which is what engine code uses. Overflow is not reported: it simply wraps, so the static_cast before adding is what keeps the arithmetic in 64 bits.

enum class keeps its values in their own namespace, so State::Walking cannot be confused with another enum's Walking and does not silently convert to a number. GDScript enum values are their integers, which is why the C++ side needs a cast to print one.

find returns a position, and the "not found" answer is the sentinel npos rather than a boolean. Godot's own String class has to_upper() and contains() just as GDScript does, so engine code reads much closer to what you already write than this column does.

Mutability is a real difference rather than a detail: a C++ string you pass to a function can be changed by it, which no GDScript string can. That is the first hint of the ownership questions the Pointers section is about.

The failed parse leaves the variable at 0, the same answer GDScript gives — but the ec field says it did not work, so the two cases are distinguishable. This is the same "was it there / what was it" split that shows up everywhere C++ can fail.

Inside the engine you would reach for Godot's Math:: functions instead, which are float-first and carry the game-flavored names you already know, such as lerp and deg_to_rad.

Godot builds with 32-bit floats for positions and vectors by default, so the suffix becomes reflex quickly. The comparison is written out because the equality you would reach for silently fails on values that are only nearly equal, which is_equal_approx exists to hide.

There is no negative indexing: loot[-1] reads memory before the array and is undefined behavior rather than an error, so back() is the spelling. Searching is a free function over a range rather than a method, which is the pattern the whole standard library follows.

at() is the checked form and throws, which is what the example uses. Engine code overwhelmingly uses [] and guarantees the index another way, so the check moves from the language into your reasoning — the single biggest change in what you are responsible for.

That substitution is the most common shape change when porting GDScript data, and it is where the compiler starts helping: enemy.hp is checked when the library is built, where enemy["hp"] could only fail once the frame ran. The const Enemy& in both the lambda and the loop avoids copying each element — see the Pointers section.

🚨 Reading a missing key with [] does not fail — it inserts one with a default value and returns that. So a typo silently grows the map instead of reporting anything, which is the opposite of what a GDScript habit expects.

Using find rather than [] is the habit to form, precisely because [] would have inserted brightness as a side effect of asking about it. found->second is the value half of the entry; first is the key.

This uses std::map rather than unordered_map because it keeps its keys sorted, so no separate sort is needed — a choice GDScript does not offer. The trade is a slower lookup, which matters only when the map is large or in a hot loop.

Braces around a single statement are optional and conventionally kept. Omitting them is how the "second line looks like it is inside the if but is not" bug happens, and C++ will not warn you because it never looked at your indentation.

🚨 A forgotten break is not an error — control falls into the next case and runs it too. That is the classic C++ bug GDScript's match cannot have, and stacking two labels as done here is the deliberate use of the same mechanism.

Both arms must produce the same type in C++, which is checked when it compiles. GDScript will happily give you a string on one branch and an integer on the other, and the surprise arrives wherever the result is finally used.

Writing std::string member instead would copy every element as the loop ran. The reference borrows it and const promises not to change it — a decision GDScript makes for you every time, and one you now make per loop.

The stop condition is written as the comparison rather than implied, so an inclusive range is a matter of changing < to <= rather than remembering that range excludes its end.

size() returns an unsigned size_t, so an int counter compared against it makes the compiler warn about a signed/unsigned comparison — and, worse, counting down past zero with an unsigned type wraps to a huge number instead of going negative. It is the most common first-week loop bug.

The annotations are optional in GDScript and mandatory here. A function must also be declared before it is used, which is why this one sits above main — order in the file matters in a way it never does in a GDScript class.

That is why spawn("slime", 2, true) has to pass the count it did not care about. The usual C++ answer is a small struct of options, which is more ceremony than GDScript needs for the same job.

The capture list is not ceremony: [factor] copies the value, while [&factor] would keep a reference that becomes dangling if the lambda outlives the variable. That is a bug class GDScript simply does not have, and the brackets are where you decide it.

The explicit std::string at the second call is doing real work: a bare "seven" is a character pointer, which converts to bool more readily than to std::string, so overload resolution can pick a surprising candidate. Overloading and implicit conversion together are one of C++'s sharpest edges.

Without the & you get a full copy — a new vector with its own elements. With it you get a second name for the original, so appending through one is visible through the other. GDScript picks per type; C++ picks per variable, per parameter, per return value.

The rule worth memorizing: const T& for anything you only read and do not want copied, T& when you intend to modify the caller's object, plain T when you want your own copy. Engine code is full of the first, and it is the single most common signature in Godot's C++.

Three pieces of punctuation do the work: &found takes an address, *target reads through it, and target->size() is shorthand for calling a method through it. 🚨 Dereferencing a null pointer is undefined behavior, not an error — this is where a habit of checking replaces GDScript telling you.

That determinism is the feature, and it has a name: RAII. Anything that must be released — a file, a lock, a buffer — is released by a destructor rather than by you remembering. Watch the output order: "snuffed" appears before "after", every run, guaranteed.

You will rarely write a bare new and never a matching delete — that pairing is what leaks when a path returns early. Inside Godot the equivalents are memnew, Ref<T> for reference-counted resources, and for a Node, ownership passes to whatever you add_child it to.

Members are private unless a public: label says otherwise, the reverse of GDScript where everything is reachable. The const after describe() promises the method changes nothing, and the compiler enforces it — a promise GDScript has no way to make.

🚨 The virtual ~Enemy() is not optional decoration. Deleting a Bat through an Enemy pointer without a virtual destructor is undefined behavior, and it is the most common way C++ inheritance goes wrong. override is what makes a misspelled method name a compile error rather than a quietly added new one.

The compiler generates a separate real function for each type used, so there is no boxing and no runtime dispatch — this is where C++'s generality is free and GDScript's is not. The cost is compile time and error messages that name the instantiation.

Look at what the GDScript column is forced to do: return the unchanged balance, which cannot be told apart from a withdrawal of zero. 🚨 The catch, for a Godot developer: Godot itself is built with exceptions disabled, so engine and GDExtension code uses error macros and return codes instead. This is a C++ feature you get in your own libraries and not inside the engine.

optional is the honest version of returning null: the absence is in the return type, so the caller cannot forget it exists. value_or supplies the fallback in one call, and this style works inside the engine too, where exceptions are off.

Both columns accumulate the same rotation, which is the part that translates unchanged — rotation is a property in GDScript and a set_rotation/get_rotation pair in C++, and they are the same engine value. What does not translate is the workflow: there is no hot reload, so changing the C++ file means rebuilding the library and restarting the editor, where GDScript reloads on save. That, rather than the syntax, is what changes day to day.

Compare the two columns line for line: signal rung(times) is ADD_SIGNAL, @export var volume is a setter, a getter and an ADD_PROPERTY, and a method callable from GDScript needs bind_method. Nothing is automatic, because the engine reads this table rather than your class.

The rule is worth stating plainly: a node you add_child is no longer yours to delete, and one you never parent is yours and will leak if you drop it. Reference-counted types use Ref<T> instead, which behaves like the GDScript object handle you are used to.

Every drawing call has the same name and the same arguments: draw_rect and draw_string are the same engine methods. The differences are all C++'s own — a struct with named fields replaces the dictionary, Ref<Font> is the reference-counted handle where GDScript just holds the object, and ThemeDB is reached through get_singleton() rather than as a global.

This row is also the clearest case for NOT reaching for C++. The per-frame work is one vector add, two comparisons and a draw_polyline; the C++ version buys nothing and costs a build step. Reach for GDExtension where the work is per element, per frame — a particle solver, a mesh build, a pathfinder over thousands of cells — because that is where the cost of crossing into script per item is what you are removing.