Блог

Сегодня я столкнулся с довольно странным случаем разрешения перегрузки. Я сократил его до следующего:

 struct S
{
    S(int, int = 0);
};

class C
{
public:
    template <typename... Args>
    C(S, Args... args);

    C(const Camp;) = delete;
};

int main()
{
    C c({1, 2});
}
  

Я полностью ожидал C c({1, 2}) , что он будет соответствовать первому конструктору C с числом переменных аргументов, равным нулю, и {1, 2} будет рассматриваться как построение списка инициализаторов S объекта.

Однако я получаю ошибку компилятора, которая указывает, что вместо этого она соответствует удаленному конструктору копирования C!

 test.cpp: In function 'int main()':
test.cpp:17:15: error: use of deleted function 'C(const C amp;)'
test.cpp:12:5: error: declared here
  

Я могу понять, как это может работать — {1, 2} может быть истолковано как допустимый инициализатор для C, при 1 этом инициализатор является инициализатором для S (который неявно конструируется из int, поскольку второй аргумент его конструктора имеет значение по умолчанию), а параметр 2 является переменным аргументом… но я не понимаю, почему это было бы лучшим совпадением, особенно учитывая, что рассматриваемый конструктор копирования удален.

Не мог бы кто-нибудь, пожалуйста, объяснить правила разрешения перегрузки, которые здесь действуют, и сказать, существует ли обходной путь, который не предполагает упоминания имени S в вызове конструктора?

РЕДАКТИРОВАТЬ: поскольку кто-то упомянул, что фрагмент компилируется с другим компилятором, я должен уточнить, что я получил вышеуказанную ошибку с помощью GCC 4.6.1.

РЕДАКТИРОВАТЬ 2: я еще больше упростил фрагмент, чтобы получить еще более тревожный сбой:

 struct S
{
    S(int, int = 0);
};

struct C
{
    C(S);
};

int main()
{
    C c({1});
}
  

Ошибки:

 test.cpp: In function 'int main()':
test.cpp:13:12: error: call of overloaded 'C(<brace-enclosed initializer list>)' is ambiguous
test.cpp:13:12: note: candidates are:
test.cpp:8:5: note: C::C(S)
test.cpp:6:8: note: constexpr C::C(const Camp;)
test.cpp:6:8: note: constexpr C::C(Camp;amp;)
  

И на этот раз GCC 4.5.1 также выдает ту же ошибку (за вычетом constexpr s и конструктора перемещения, которые он не генерирует неявно).

Мне очень трудно поверить, что это то, что задумали разработчики языка…

Для C c({1, 2}); вас есть два конструктора, которые можно использовать. Итак, происходит разрешение перегрузки и выясняется, какую функцию использовать

 C(S, Args...)
C(const Camp;)
  

Args будет выведено к нулю, как вы выяснили. Таким образом, компилятор сравнивает построение S с построением C временного out of {1, 2} . Построение S из {1, 2} является прямым и использует ваш объявленный конструктор S . Построение C из {1, 2} также является прямым и использует ваш шаблон конструктора (конструктор копирования нежизнеспособен, потому что он имеет только один параметр, но передаются два аргумента — 1 и 2 — are). Эти две последовательности преобразования несопоставимы. Таким образом, два конструктора были бы неоднозначными, если бы не тот факт, что первый является шаблоном. Таким образом, GCC предпочтет не-шаблон, выбрав конструктор удаленной копии и выдаст вам диагностику.

Теперь для вашего C c({1}); testcase можно использовать три конструктора

 C(S)
C(C constamp;)
C(C amp;amp;)
  

Для двух последних компилятор предпочтет третий, потому что он связывает rvalue с rvalue . Но если вы считаете C(S) против, C(Camp;amp;) вы не найдете победителя между двумя типами параметров, потому что for C(S) вы можете создать S из a, {1} а for C(Camp;amp;) вы можете инициализировать C временный из a {1} , используя C(S) конструктор (стандарт явно запрещает определяемые пользователем преобразования для параметра конструктора перемещения или копирования, которые можно использовать для инициализацииобъекта класса C from {...} , поскольку это может привести к нежелательным неоднозначностям; вот почему преобразование 1 в Camp;amp; здесь не рассматривается, а только преобразование из 1 в S ). Но на этот раз, в отличие от вашего первого тестового примера, ни один из конструкторов не является шаблоном, поэтому в итоге возникает двусмысленность.

Это полностью то, как все должно работать. Инициализация в C странная, поэтому, к сожалению, получить все «интуитивно понятное» для всех будет невозможно. Даже простой пример, приведенный выше, быстро усложняется. Когда я написал этот ответ и через час случайно просмотрел его снова, я заметил, что что-то упустил, и мне пришлось исправить ответ.

Возможно, вы правы в своей интерпретации того, почему он может создать a C из этого списка инициализаторов. ideone с радостью компилирует ваш пример кода, и оба компилятора не могут быть корректными. Однако предполагается, что создание копии допустимо…

Итак, с точки зрения компилятора, у него есть два варианта: создать новый S{1,2} и использовать шаблонный конструктор или создать новый C{1,2} и использовать конструктор копирования. Как правило, не шаблонные функции предпочтительнее шаблонных, поэтому выбирается конструктор копирования. Затем он проверяет, можно ли вызвать функцию … она не может, поэтому выдает ошибку.

Для SFINAE требуется ошибка другого типа… они возникают на первом шаге, когда проверяется, какие функции являются возможными совпадениями. Если простое создание функции приводит к ошибке, эта ошибка игнорируется, и функция не рассматривается как возможная перегрузка. После перечисления возможных перегрузок подавление ошибок отключается, и вы зависаете с тем, что получаете.