Move Semantics In Unreal Engine

Source: Dev.to

The Copy Problem

In traditional C++98 programming you had two ways in which objects were created: from scratch and from copying.

Foo();                     // Default ctor
Foo(int x);                // Parameterized ctor
Foo(const Foo& rhs);       // Copy ctor
Foo& operator=(const Foo& rhs); // Copy assignment

Copying is usually more processor‑intensive. To overcome this, C++11 introduced move semantics.

Foo(Foo&& rhs);            // Move ctor
Foo& operator=(Foo&& rhs); // Move assignment

Moving objects can be more memory‑efficient than copying (though not always).

When to Implement Special Functions

Deciding whether to implement custom move constructors boils down to the Rule of Three/Five/Zero. Ask yourself: Does your type manage ownership or dynamic resources?

For Plain Old Data Types

For POD types or members, moving is essentially the same as copying. Consider the difference when adding instances of the following types to a std::vector:

// No reallocation needed; pointer to dynamic memory can be copied
// sizeof(Foo) = 24 (gcc, Win64)
struct Foo {
    std::vector numbers; // dynamic vector with 1000 entries
};

// Full copy required; all data must be duplicated
// sizeof(Bar) = 4000 (gcc, Win64)
struct Bar {
    int numbers[1000];
};

Unreal Engine Terminology

Unreal Engine uses its own naming conventions and provides smart‑pointer equivalents to the standard library:

• TUniquePtr
• TSharedPtr
• TWeakPtr

Note:

• UObjects cannot be moved or referenced by smart pointers; they are always managed by the garbage collector and referenced by raw pointers.
• Functions with r‑value‑reference or smart‑pointer parameters are not Blueprint‑exposable.
• UStructs may define custom move functionality, but they rarely benefit because they are usually plain data structs.