Copy, move, and the rule of zero

Copy and move are operations chosen by an expression's value category and the available overloads. std::move is a cast that permits move overload selection; it does not itself transfer a byte. A const object usually cannot call a normal T(T&&) move constructor, so moving it may copy instead.

std::vector<Int> original{1,2,3};
auto copy=original;           // independent element storage
auto owner=std::move(copy);  // permits ownership transfer
// copy is valid; use only operations whose preconditions still hold.

Moved-from standard containers remain valid but their exact state is generally unspecified. Do not build an API around an assumed empty source unless the API establishes that explicitly. References to transferred vector elements may remain tied to the transferred allocation, but invalidation rules depend on the operation and allocator; document which addresses matter.

A class made entirely of owning value members often needs no custom destructor, copy, or move operation: the rule of zero. A custom destructor can inhibit implicit move generation; a handwritten copy of a raw owning pointer can cause double deletion. Prefer vector/string/unique_ptr members to manual arrays. Unique ownership naturally disables copying; value vectors naturally deep-copy their elements.

struct Packet {std::vector<Int> values;}; // member semantics compose
static_assert(std::is_copy_constructible_v<Packet>);
static_assert(std::is_move_constructible_v<Packet>);

Use a by-value parameter when the function needs an owned working copy and callers may choose to copy or move into it. The final exercise drains a prefix of packets: transfer each inner vector's allocation, then erase the consumed outer entries. Validate the count before any move, so invalid requests leave all inner contents unchanged. The outer erase invalidates references to moved/shifted Packet objects even though transferred inner Int buffers remain owned by the result.