Допустим такая обертка над std::vector:

#include <vector>
#include <cstdint>
#include <cstring>

class MyClass
{
private:
    std::vector<uint8_t> data;

public:
    MyClass() : data(100) {}

    void setHeader(uint32_t value)
    {
        std::memcpy(data.data(), &value, sizeof(value));
    }

    // ... еще устанавливаем разные части бинарного пакета

    const std::vector<uint8_t>& getData() const
    {
        return data;
    }
};

Не очень красиво что при обращении:

std::vector<uint8_t> t = obj.getData();

— будет создавать полную копию всех данных. Как бы постоянная ловушка. Т.е. нужно не забывать писать:

std::vector<uint8_t>& t = obj.getData();

И далее. Что если я захочу в итоге переместить данные, забрать владение у MyClass — как красивее оформить?

std::vector<uint8_t> takeData()
{
    return std::move(data);
}

Вот тут что-то об этом в самом низу: https://pvs-studio.ru/ru/blog/terms/6516/

Здесь вызов std::move следует убрать. Несмотря на то, что в коде пытаются "подсказать" компилятору, что возвращаемый объект следует перемещать, а не копировать, используя функцию std::move, компилятор будет обязан сгенерировать более медленный ассемблерный код.

Дело в том, что возвращаемый объект – это результат вызова std::move, его тип будет Res &&. Тип фактически возвращаемого объекта и тип возвращаемого объекта по сигнатуре функции различны. Следовательно, компилятор не сможет применить для функции foo NRVO, и мы имеем дело не с оптимизацией, а с пессимизацией.

Более того, согласно стандарту C++11, если компилятор не сможет применить необязательную оптимизацию, то он должен сначала применить конструктор перемещения и лишь затем конструктор копирования для локальных переменных или формальных параметров функции.

Честно сказать, не уверен что это к данному случаю. Но как-то все слишком завязано на эти хитрые трюки компилятора по оптимизации, а хотелось бы простоты в данном случае. Даже не полагаться на RVO (вдруг где-то не сработает) это — забрать владение чисто и прозрачно.