Согласно стандарту C++ (в частности [over.ics.list]), при выполнении инициализации списков компилятор пытается сопоставить braced-init-list с конструкторами, принимающими std::initializer_list<T>. Это связывание является преобразованием идентичности (точное совпадение), которое превалирует над пользовательскими преобразованиями, необходимыми для того, чтобы сопоставить отдельные элементы с конструкторами, не использующими initializer_list. В результате, конструктор Container(size_t count, T value) проигрывает Container(std::initializer_list<T>), когда он вызывается с {10, 20}, поскольку последний не требует преобразования для аргумента braced-init-list, независимо от сужения по элементам.
Мы разрабатывали класс Matrix для графического движка, который предоставлял как конструктор заполнения Matrix(size_t rows, size_t cols, double val), так и конструктор стиля агрегата Matrix(std::initializer_list<std::initializer_list<double>>) для инициализации таблиц литералов. Начинающий разработчик написал Matrix m{1080, 1920, 0.0}, ожидая матрицу 1080x1920, инициализированную нулями, но вместо этого программа создала матрицу 1x3, содержащую три скалярных значения, что привело к тонкому сбою рендеринга во время выполнения, который было сложно отследить при отладке.
Сначала мы рассматривали введение синтаксиса с использованием круглых скобок Matrix(1080, 1920, 0.0) для конструктора заполнения, чтобы обойти перегрузку std::initializer_list. Однако это нарушало предпочтения нашего кодового стандарта в пользу однородной инициализации C++11 и создавало несогласованный API, где некоторые конструкторы требовали круглые скобки, в то время как другие использовали фигурные.
Затем мы исследовали диспетчеризацию по тегам, добавив параметр fill_tag_t к конструктору заполнения, эффективно заставляя пользователей писать Matrix{fill_tag, 1080, 1920, 0.0}. Хотя это устранило неоднозначность вызова, оно загромождало публичный интерфейс и путало разработчиков, ожидавших интуитивно понятные сигнатуры конструкторов без искусственных типов тегов.
В-третьих, мы пытались ограничить конструктор std::initializer_list так, чтобы он активировался только для вложенных фигурных скобок через SFINAE на параметре шаблона. Этот подход сломал законные случаи использования, такие как Matrix{{1.0, 2.0}, {3.0, 4.0}}, и ввел хрупкое метапрограммирование шаблонов, что увеличивало время компиляции и сложность сообщений об ошибках.
В конечном итоге мы решили ввести статическую фабричную функцию Matrix::filled(rows, cols, val) и сделали конструктор со тремя параметрами приватным, направив пользователей к явному синтаксису для построения на основе размеров, сохранив при этом конструктор std::initializer_list публичным для агрегатного синтаксиса. Это сохранило интуитивную инициализацию фигурными скобками для литеральных таблиц, избегая случайной неверной интерпретации аргументов размеров.
Рефакторинг API предотвратил первоначальную ошибку, сделав Matrix{1080, 1920, 0.0} ошибкой на стадии компиляции без соответствующего публичного конструктора. Теперь разработчики были вынуждены использовать либо Matrix::filled(1080, 1920, 0.0) для операций заполнения, либо Matrix{{...}} для списков инициализации, что значительно улучшило ясность и безопасность кода.
Как компилятор ранжирует последовательность преобразования от braced-init-list к конструктору, не использующему initializer_list, по сравнению с совпадением идентификатора конструктора initializer_list?
Согласно правилам разрешения перегрузки стандарта C++ для инициализации списков, связывание braced-init-list с параметром std::initializer_list<T> представляет собой преобразование идентичности (точное совпадение) с самым высоким рангом. В отличие от этого, сопоставление того же braced-init-list с другим конструктором требует, чтобы компилятор рассматривал список как список выражений в круглых скобках и выполнял пользовательские или стандартные преобразования для каждого элемента. Поскольку преобразования идентичности превосходят все другие последовательности преобразования, конструктор initializer_list выигрывает, даже если его типы элементов хуже логически совпадают, чем те, которые требуются альтернативным конструктором.
Почему auto x = {1, 2, 3}; выводит std::initializer_list<int> в C++11 и C++14, тогда как auto x{1, 2, 3} становится некорректным в C++17 и более поздних версиях?
До C++17 копийная инициализация списков с использованием токена = с auto всегда выводила std::initializer_list для braced-init-lists. Однако C++17 ввел новые правила для прямой инициализации списков с auto (без =), которые выполняют стандартное выведение аргументов шаблона: если braced-init-list содержит несколько элементов, выведение завершится неудачей, поскольку auto не может представить std::initializer_list в этом контексте, делая программу некорректной. Это изменение устраняет "секретную std::initializer_list" ловушку для прямой инициализации, однако кандидаты часто упускают из виду, что синтаксис копирования (auto x = {...}) по-прежнему выводит std::initializer_list даже в современном C++, создавая тонкую непоследовательность между стилями инициализации.
В каком сценарии класс с конструкторами initializer_list и конструктором с вариативными шаблонами может разрешать неоднозначность, и как std::in_place_t может ее устранить?
Когда класс предоставляет как Container(std::initializer_list<T>), так и template<typename... Args> Container(Args&&... args), вариативный пакет может соответствовать тем же аргументам, что и конструктор initializer_list через выведение аргументов шаблона. Для Container c{1, 2, 3} оба конструктора являются жизнеспособными: первый через преобразование идентичности braced-init-list, а второй через выведение Args как int, int, int. Хотя конструктор non-template с initializer_list обычно выигрывает в финальном сравнении, добавление типа тегов, такого как std::in_place_t, к вариативному конструктору (например, Container(std::in_place_t, Args&&... args)) заставляет пользователей писать Container{std::in_place, 1, 2, 3}, обеспечивая, что вариативная версия вызывается только явно, в то время как конструктор initializer_list обрабатывает однородные braced списки по умолчанию.