Практическая ситуация: у класса нет конструктора без аргументов; объявлены конструктор из одного значения и конструктор, принимающий список инициализации. Какой конструктор выберет пустая фигурная инициализация объекта?
Пустая фигурная инициализация выберет конструктор, принимающий список инициализации, если у класса нет конструктора без аргументов. Пустой список является допустимым аргументом для std::initializer_list, поэтому конструктор из одного значения не используется.
Если у класса есть конструктор без аргументов, для пустых фигурных скобок действует специальное правило: сначала выбирается обычный конструктор без аргументов, а не конструктор списка инициализации.
Фигурная инициализация появилась в C++11 как единый синтаксис для инициализации встроенных типов, массивов и объектов классов. Одновременно появился механизм конструкторов со std::initializer_list, позволяющий создавать объекты из последовательности значений.
Единый синтаксис сделал возможными конструкции вроде создания контейнера из набора элементов, но потребовал специальных правил разрешения перегрузок. Иначе добавление конструктора списка инициализации неожиданно меняло бы смысл уже существующих вызовов.
Рассмотрим класс без конструктора по умолчанию, у которого есть конструктор из одного значения и конструктор списка инициализации. При создании объекта пустыми фигурными скобками визуально неясно, означает ли это вызов конструктора без аргументов или передачу пустого набора элементов.
Ошибка в понимании механизма может привести к выбору не того конструктора, побочным эффектам в его теле или неожиданному поведению после добавления новой перегрузки. Особенно важно это для контейнеров и пользовательских типов, где пустой список может иметь отдельную семантику.
Для list-initialization перегрузки анализируются в два этапа. Сначала рассматриваются конструкторы, принимающие std::initializer_list; если подходящий конструктор найден, обычные конструкторы не участвуют в выборе.
Пустой список также может быть аргументом std::initializer_list: он просто содержит ноль элементов. Поэтому при отсутствии конструктора без аргументов конструктор списка инициализации считается подходящим даже для пустых фигурных скобок.
В этом примере будет выбран конструктор Packet(std::initializer_list<int>), поэтому программа выведет list. Конструктор Packet(int) не подходит: пустой список не превращается в отсутствующее значение типа int.
Важное исключение касается класса с конструктором без аргументов. Для пустой инициализации такого класса обычный конструктор без аргументов выбирается напрямую; наличие конструктора std::initializer_list не заставляет его перехватывать вызов.
Если список непустой, преимущество конструктора std::initializer_list проявляется явно. Например, при наличии конструкторов из одного int и из std::initializer_list<int> инициализация одним целым значением через фигурные скобки выберет список инициализации.
Элементы списка инициализации инициализируются с проверкой запрещённых сужающих преобразований. Поэтому фигурная инициализация может завершиться ошибкой там, где круглая инициализация разрешила бы преобразование, например из вещественного значения в целое.
У конструктора списка инициализации есть и практический компромисс: он делает интерфейс удобным для наборов элементов, но может изменить выбор перегрузки после добавления в класс новой функции-конструктора. Такое изменение способно нарушить исходную семантику клиентского кода.
В библиотеке сообщений был класс Packet. Изначально объект создавался из одного числового размера. Позже добавили конструктор std::initializer_list<int>, чтобы удобно формировать пакет из набора полей. Старый вызов с пустыми фигурными скобками стал особенно подозрительным: при отсутствии конструктора по умолчанию он начал обращаться к конструктору списка.
Рассматривались два варианта. Первый — оставить перегрузки как есть и документировать, что пустые скобки означают пустой список; это сохраняет краткий синтаксис, но повышает риск неправильного понимания. Второй — добавить явно названный фабричный метод для создания пустого пакета; он понятнее по смыслу, но делает интерфейс более многословным.
Выбранным решением стало явное разделение операций: конструктор списка оставили для набора полей, а создание пустого пакета перенесли в фабричный метод. Это исключило зависимость поведения от тонких правил перегрузки и сделало код вызова самодокументируемым.
std::initializer_list?Нет. Если у класса есть доступный конструктор без аргументов, пустая фигурная инициализация выбирает его. При отсутствии такого конструктора список инициализации может стать выбранной перегрузкой, даже если он пуст.
Это правило позволяет контейнерам и обычным классам корректно поддерживать естественное создание пустого объекта. Поэтому для точного ответа нужно учитывать не только наличие initializer_list, но и наличие доступного конструктора по умолчанию.
std::initializer_list объявлен explicit?При прямой инициализации фигурными скобками, например при непосредственном создании объекта, такой конструктор может быть выбран. Но при copy-list-initialization, когда объект инициализируется через присваивающий синтаксис с фигурными скобками, выбранный explicit-конструктор делает инициализацию некорректной.
Это ограничение защищает от неявного преобразования списка в объект. Поэтому вид инициализации — прямая или копирующая — влияет не только на синтаксис, но и на допустимость выбранной перегрузки.
Потому что конструкторы std::initializer_list получают приоритет в разрешении перегрузки для непустой фигурной инициализации. Вызов, который раньше обращался к конструктору из одного значения, после добавления списка может начать передавать это значение как единственный элемент списка.
Изменится не только выбранная функция, но и возможные преобразования, проверка сужения и смысл аргумента. Поэтому добавление initializer_list в публичный класс следует рассматривать как изменение интерфейса, требующее проверки всех мест, где объект создаётся фигурной инициализацией.