Ответ.

POD (Plain Old Data) — это структура или тип данных в C++, который совместим с обычным структурированием данных как в C и идеально подходит для низкоуровневого программирования.

История вопроса:

POD возник как наследие от языка Си, чтобы гарантировать совместимость памяти между C и C++. В C++98 POD-объекты имели жёсткие ограничения, чтобы их можно было легко копировать побайтово или сериализовывать напрямую.

Проблема:

Многие программисты путают POD с просто простыми структурами и не учитывают нюансы стандарта, например, правила агрегации или наличие нестандартных конструкторов, что критично в ABI-совместимости и низкоуровневых операциях (memcpy, сериализация).

Решение:

В современном C++ с C++11 введены понятия trivial, trivially copyable и standard-layout, разделив требования более чётко.

POD: стандартное представление, только простые типы, нет пользовательских конструкторов, деструкторов, виртуальных функций, приватного наследования.
Trivially copyable: можно копировать через memcpy, копирующий и перемещающий конструкторы, а также деструкторы — тривиальные.
Standard-layout: никакого виртуального наследования, общая упорядоченность размещения членов, совместимость с C ABI (можно безопасно привести к char*).

Пример кода:

struct PODType {
    int x;
    double y;
};

static_assert(std::is_pod<PODType>::value, "Must be POD");
static_assert(std::is_trivially_copyable<PODType>::value, "Trivially copyable");
static_assert(std::is_standard_layout<PODType>::value, "Standard layout");

Ключевые особенности:

Идеальны для сериализации, обмена данными между C и C++.
Не поддерживают инкапсуляцию (все члены должны быть однородно доступны).
Не допускают нестандартных конструкторов, наследования с виртуалами.

Вопросы с подвохом.

Можно ли сделать POD-тип с приватными членами?

Нет, стандарт-layout требует либо все члены public, либо однородный доступ (либо все public, либо все private/protected).

Будет ли класс POD-типом, если в нем явно определён пользовательский конструктор без тела?

Нет, наличие пользовательского (даже пустого) конструктора делает тип не POD и не тривиальным.

Могу ли использовать POD-тип с виртуальным деструктором или виртуальными функциями?

Нет, виртуальные методы делают тип не POD и не стандарт- layout.

Типовые ошибки и анти-паттерны

Сериализация или copy-paste через memcpy не для trival/nonPOD объектов.
Использование нестандартных конструкторов в POD-типах, что ломает бинарную совместимость.
Усложнение структуры POD, смешивание стиля C и C++.

Пример из жизни

Негативный кейс

Разработчик сериализует структуру через memcpy, не заметив, что в ней добавлен std::string (не POD), данные становятся некорректными на чтении.

Плюсы:

Легко внедрять на этапе прототипирования со структурами C.

Минусы:

Неявные баги, несовместимость с C++-объектами.

Позитивный кейс

Вся структура — POD или trival, сериализация — через memcpy, никаких ссылок и std-контейнеров внутри.