Список инициализации: корректность, а не стиль

1. Введение

Если вы только начинаете, легко подумать: «Ну в конструкторе же можно написать field_ = value; — и всё». Иногда можно. Но это опасное упрощение. Конструктор выполняется тогда, когда объект ещё рождается, и у C++ есть чёткий порядок: сначала создаются поля, а уже потом выполняется тело конструктора. Список инициализации (: field_(value)) — это способ создать поля сразу правильными, а не создавать “как получится” и потом перекидывать значение присваиванием.

Представьте, что вы заказали пиццу. Инициализация — это когда пицца приехала уже с сыром и начинкой. Присваивание — это когда вам привезли пустое тесто, и вы такие: «О, сейчас я сам сверху всё положу». Иногда можно, но зачем страдать и почему вы вообще платите доставке.

Мини-схема “что происходит при создании объекта”

flowchart TD
    A[Вы выделяете место под объект] --> B["Инициализируются поля (и базовые части)"]
    B --> C[Выполняется тело конструктора]
    C --> D[Объект готов к использованию]

Ключевое здесь: поля инициализируются до тела конструктора. Поэтому список инициализации — это не «синтаксический сахар», а механизм, который работает в правильный момент.

2. Синтаксис списка инициализации

Когда вы впервые видите конструктор со списком инициализации, он выглядит как будто кто-то случайно поставил двоеточие и запятые. На самом деле всё довольно прямолинейно: после параметров конструктора идёт двоеточие, а дальше — перечень, как каждое поле нужно инициализировать. Каждая часть field_(...) означает: «создай поле field_ сразу вот с таким значением». Это именно создание поля, а не “потом присвоим”.

Давайте начнём строить наш мини‑проект: простую модель задачи для CLI‑трекера дел (что-то вроде “самый маленький Todo”, который не обещает вам новую жизнь по понедельникам).

Пример 1: правильный конструктор Task со списком инициализации

#include <string>

class Task {
    int id_;
    std::string title_;
    bool done_;
public:
    Task(int id, const std::string& title)
        : id_(id)
        , title_(title)
        , done_(false)
    {}
};

Здесь важно уловить смысл: id_, title_, done_ не “получают значения”, а создаются сразу с нужными значениями.

Чуть позже мы добавим методы и распечатаем задачу, но сначала закрепим: вот это — “правильный стиль” не потому, что так красивее. А потому, что так правильнее по смыслу.

3. Инициализация и присваивание в конструкторе

На простых типах (int, bool) часто кажется, что разницы нет. И правда, в очень простых случаях оптимизатор может «схлопнуть» лишнее. Но как только поля становятся более “живыми” (например, std::string, std::vector), разница становится не философской, а практической: либо вы создаёте поле сразу нужным, либо вы сначала создаёте его “пустым”, а потом заставляете его перестраиваться.

Важная мысль: если вы пишете в теле конструктора title_ = title;, то к этому моменту title_ уже как-то создан. Обычно как пустая строка. И вы делаете вторую операцию: присваивание. То есть два шага вместо одного.

Пример 2: «работает, но не то, что мы хотим»

#include <string>

class Task {
    int id_;
    std::string title_;
    bool done_;
public:
    Task(int id, const std::string& title) {
        id_ = id;           // присваивание
        title_ = title;     // присваивание (строка уже была создана)
        done_ = false;      // присваивание
    }
};

Этот код компилируется и будет работать. Но вы как будто говорите компилятору: «Создай мне объект как-нибудь, а потом я его пересоберу изнутри». Для простых полей это не всегда критично. Но дальше мы увидим случаи, когда так делать вообще нельзя — и вот там начинается настоящая “корректность, а не стиль”.

4. Когда список инициализации обязателен: const и ссылки

Сейчас будет момент, когда C++ очень строго скажет: «Нет». И это хороший момент, потому что язык здесь защищает вас от опасной модели “потом присвою”. Есть поля, которые нельзя сначала создать “пустыми”, а потом присвоить. Классические примеры — const‑поля и ссылки.

Причина простая: const означает «это значение нельзя менять после создания». А ссылку нельзя “перепривязать” к другому объекту: она обязана ссылаться на что-то с самого рождения.

Пример 3: const‑поле — только список инициализации

#include <string>

class Task {
    const int id_;
    std::string title_;
public:
    Task(int id, const std::string& title)
        : id_(id)        // обязано быть здесь
        , title_(title)
    {}
};

Если вы попытаетесь написать id_ = id; в теле конструктора, компилятор справедливо возмутится: id_ нельзя присваивать, потому что он const.

В документах стандарта для инициализации членов есть отдельная терминология про “инициализаторы членов” и то, что они применяются к конкретным (direct) нестатическим членам. Даже если мы не читаем стандарт как роман перед сном, полезно знать, что это не “совет”, а часть строгих правил языка.

Пример 4: ссылка‑поле

#include <string>

class TaskView {
    const std::string& title_ref_;
public:
    TaskView(const std::string& title)
        : title_ref_(title)
    {}
};

Я сразу предупрежу: хранить ссылки как поля — почти всегда “тонкий лёд”, потому что нужно следить за временем жизни объекта, на который ссылаемся. Но как учебный пример это идеально показывает правило: ссылку нельзя сначала “создать пустой”, а потом присвоить.

5. Конструктор и инварианты: валидное состояние сразу

До этого момента мы говорили в основном о механике. Теперь — о смысле. Если вы проектируете класс, его конструктор — это место, где вы обязаны обеспечить минимальную корректность: чтобы объект нельзя было создать “битым”. И список инициализации помогает вам в этом, потому что он задаёт начальные значения именно там, где им и положено появляться.

Представим правило нашего приложения: задача не может иметь отрицательный id. Мы можем “нормализовать” входные данные — например, если пришло отрицательное, сделать 0. Это не идеальная бизнес-логика, но как пример инварианта подойдёт.

Пример 5: нормализация в списке инициализации

#include <string>

class Task {
    int id_;
    std::string title_;
    bool done_;
public:
    Task(int id, const std::string& title)
        : id_(id < 0 ? 0 : id)
        , title_(title)
        , done_(false)
    {}
};

Здесь мы явно показываем: объект не может родиться с id_ = -50. Мы не оставляем это на «потом кто-нибудь проверит». Это и есть взрослая модель: конструктор — точка входа в валидность.

6. Default member initializer и список инициализации

Пока мы строили Task, вы могли заметить: многие поля имеют очевидные значения по умолчанию. Например, done_ логично начинать с false. В C++ можно задавать значения по умолчанию прямо при объявлении поля. Тогда конструктор будет проще, а класс — понятнее: вы буквально читаете поля и сразу видите “обычное состояние” объекта.

Важно понимать приоритет: если поле не указано в списке инициализации, тогда используется значение по умолчанию у поля (если оно есть). Это позволяет не дублировать одно и то же в каждом конструкторе.

Пример 6: значения по умолчанию у полей

#include <string>

class Task {
    int id_ = 0;
    std::string title_ = "untitled";
    bool done_ = false;
public:
    Task(int id, const std::string& title)
        : id_(id)
        , title_(title)
    {}
};

В этом варианте done_ не упоминается в списке инициализации, потому что у него уже есть разумное значение “по умолчанию”. Такой код легче поддерживать: меньше повторов, меньше шанс забыть инициализировать поле.

7. Мини-использование в main

До этого мы писали классы “в вакууме”. Но мозгу новичка важно увидеть, что объект реально создаётся, реально живёт, и методы реально работают. Поэтому добавим маленький функционал: чтение полей через const‑методы и печать задачи. Это продолжает линию предыдущего дня: инкапсуляция и минимальный интерфейс.

Список инициализации здесь остаётся главным героем: именно он делает так, что Task всегда появляется в предсказуемом состоянии.

Пример 7: Task с методами и печатью

#include <iostream>
#include <string>

class Task {
    int id_;
    std::string title_;
    bool done_;
public:
    Task(int id, const std::string& title)
        : id_(id)
        , title_(title)
        , done_(false)
    {}

    int id() const { return id_; }
    bool done() const { return done_; }

    void mark_done() { done_ = true; }

    void print() const {
        std::cout << "#" << id_ << " " << title_
                  << (done_ ? " [done]" : " [todo]") << '\n';
        // например: #1 Buy milk [todo]
    }
};

int main() {
    Task t{1, "Buy milk"};
    t.print();        // #1 Buy milk [todo]
    t.mark_done();
    t.print();        // #1 Buy milk [done]
}

Обратите внимание, насколько спокойной становится логика main: мы создаём объект, и он уже сразу готов к использованию. Это “тонкий main” в миниатюре: чем больше логики инициализации спрятано в конструкторе, тем меньше хаоса в коде вокруг.

8. Полезные нюансы

Mem-initializer — отдельная часть конструктора

Иногда новички воспринимают список инициализации как “продолжение тела” или как “место, где тоже можно писать обычный код”. Лучше думать иначе: у конструктора есть две части — “инициализационная” и “исполняемая”. Список инициализации — это часть, которая говорит, как создавать члены. Тело — это часть, которая говорит, что делать после создания.

В терминах стандарта вы можете встретить формулировки про mem-initializer и про идентификаторы инициализируемых членов. Мы не изучаем стандарт построчно, но полезно знать, что синтаксис здесь не случайный: это отдельный механизм языка, а не “хитрый стиль оформления”.

Практический вывод очень простой: если вы хотите задать стартовые значения полям — делайте это в списке инициализации (или через значения по умолчанию у полей). Если вы хотите выполнить действия, которые должны происходить после инициализации (например, вывести сообщение, посчитать что-то и т.д.) — это уже тело конструктора.

Таблица-памятка: когда что использовать

Чтобы не держать всё в голове, полезно один раз зафиксировать разницу в виде маленькой таблицы. Она не заменяет понимание, но отлично помогает, когда вы через неделю открываете код и думаете: «Так… а почему тут двоеточие, и почему я не могу просто присвоить?».

Обратите внимание: “значения по умолчанию у поля” и “список инициализации” — это не конкуренты. Они обычно работают вместе: значения по умолчанию задают “обычную норму”, а конструктор уточняет, когда пользователь передал параметры.

9. Типичные ошибки

Ошибка №1: путать инициализацию и присваивание и писать всё в теле конструктора.
На первых порах это выглядит логично: «конструктор же выполняется — значит, можно присвоить». Но поля к моменту тела конструктора уже созданы. Для int это часто прокатывает незаметно, а для std::string и других сложных типов вы получаете лишнюю работу. Для const и ссылок вы вообще получите ошибку компиляции.

Ошибка №2: считать список инициализации “стилем”, который можно игнорировать.
Это одна из самых вредных установок. Список инициализации нужен не для красоты кода и не для “программистского снобизма”. Он нужен потому, что в C++ есть строгий порядок создания объекта, и некоторые поля можно корректно задать только в момент их создания.

Ошибка №3: пытаться обеспечить валидность объекта “снаружи”, а не внутри конструктора.
Если класс допускает создание “битых” объектов, вы неизбежно получите баги: где-то забыли вызвать сеттер, где-то перепутали порядок вызовов, где-то выбросили объект в контейнер и забыли “донастроить”. Конструктор и список инициализации позволяют сделать так, чтобы объект был нормальным сразу после Task t{...};

Ошибка №4: делать поля const/ссылками и потом удивляться, что “не присваивается”.
Это не каприз компилятора, а логика языка: const и ссылки должны получить значение при инициализации. Иногда это заставляет аккуратнее проектировать модель данных — и это тоже плюс: язык мягко намекает, что “жизнь объекта” начинается в конструкторе, а не после него.