Краткий ответ

При default-initialization встроенные поля класса обычно не получают начального значения: их значение становится неопределённым. При value-initialization объект сначала обнуляется, если его default-конструктор не является пользовательским, поэтому встроенные поля получают нулевые значения.

Это различие определяется не только наличием конструктора, но и тем, является ли он user-provided. Пустой пользовательский конструктор не даёт автоматического обнуления полей при value-initialization.

Исторический контекст

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

Различие между default-initialization и value-initialization позволяет отдельно выразить намерение: создать объект с минимальными затратами или получить его нулевое начальное состояние. Фигурные скобки стали распространённым способом явно запросить value-initialization.

Постановка проблемы

Если программист ожидает, что обычное создание объекта автоматически обнулит его поля, он может получить неопределённые значения. Чтение такого значения для объекта встроенного типа обычно приводит к неопределённому поведению, а результат может зависеть от содержимого памяти.

Обратная ошибка тоже возможна: бездумная value-initialization больших объектов может приводить к дополнительной инициализации памяти. Кроме того, добавление пустого пользовательского конструктора способно изменить результат value-initialization и нарушить предположение о нулевых значениях.

Подробное решение

При default-initialization локальный объект класса создаётся вызовом подходящего default-конструктора. Если конструктор не задаёт значение поля встроенного типа и у поля нет default member initializer, такое поле остаётся неинициализированным.

При value-initialization объекта класса, у которого default-конструктор не является пользовательским, сначала выполняется zero-initialization, а затем обычная инициализация. Поэтому поля встроенных типов получают нули, если их последующая инициализация не задаёт иное значение.

struct Plain {
    int count;
};

struct WithCtor {
    int count;
    WithCtor() {}
};

Plain a;          // count имеет неопределённое значение
Plain b{};        // count равен 0
WithCtor c{};     // count не обнуляется автоматически
WithCtor d{ };    // тот же результат: пустой user-provided ctor

В Plain b{} срабатывает value-initialization: неявно объявленный default-конструктор не является пользовательским, поэтому поле предварительно обнуляется. В WithCtor c{} вызывается пользовательский конструктор; его пустое тело не инициализирует count, поэтому поле сохраняет неопределённое значение.

Default member initializer меняет ситуацию независимо от выбранной формы инициализации, если конструктор использует это поле по умолчанию. Например, поле с инициализатором int count = 0 получает ноль при построении объекта, если конструктор явно не задал другое значение.

Для встроенных типов в локальных объектах безопаснее явно задавать начальные значения или использовать default member initializers. Однако нельзя сводить правило к формуле «фигурные скобки всегда обнуляют объект»: пользовательский default-конструктор и явные инициализаторы могут изменить результат.

Ситуация из практики

В контейнере хранились записи статистики с полями-счётчиками. Разработчик добавил пустой конструктор для совместимости с фабрикой и сохранил создание записей через пустые фигурные скобки, ожидая нулевых счётчиков. После этого часть записей содержала неопределённые значения, потому что пользовательский конструктор не инициализировал поля.

Рассматривались три варианта:

оставить пустой конструктор и явно инициализировать каждое поле в его списке инициализации — надёжно, но требует поддерживать список при добавлении полей;
убрать конструктор и использовать default member initializers — компактно и хорошо соответствует правилу нулевого конструктора;
перед каждой операцией обнулять объект извне — скрывает инварианты класса и создаёт риск пропустить место инициализации.

Выбрали default member initializers, поскольку нулевое состояние являлось частью инварианта записи. В результате создание объекта стало безопасным независимо от места вызова, а добавление новых полей требовало меньше изменений.

Что кандидаты часто упускают

1. Обнуляет ли value-initialization объект с пользовательским пустым default-конструктором?

Нет, автоматически рассчитывать на это нельзя. Если default-конструктор является user-provided, перед его выполнением не происходит требуемого для данного случая предварительного zero-initialization; поля, которые конструктор не инициализирует, могут остаться с неопределёнными значениями.

Поэтому пустой конструктор не эквивалентен отсутствующему конструктору. Для гарантии нужно явно инициализировать поля в списке инициализации или задать default member initializers.

2. Что произойдёт с полем, если у него есть default member initializer?

Default member initializer используется, когда конкретный конструктор не указал иное значение для поля. Например, int count = 0 обеспечивает нулевую инициализацию count и при default-initialization, и при value-initialization объекта.

Если конструктор явно задаёт count в списке инициализации, default member initializer для этого вызова игнорируется. Явная инициализация конструктора имеет приоритет.

3. Одинаковы ли последствия для объектов с автоматическим и статическим временем жизни?

Нет. Объекты со статическим или thread-local временем жизни проходят zero-initialization до динамической инициализации независимо от того, как записано их объявление. Поэтому встроенное поле глобального объекта обычно начинает с нулевого значения.

Это не означает, что тот же тип безопасен как локальная переменная: локальный объект при default-initialization не получает автоматического обнуления. Нельзя переносить вывод о начальном состоянии между разными категориями времени жизни объекта.