Как устранить эту конструкцию в шаблоном конверсионном операторе?

После путаницы, почему мой код дал мне ошибку двусмысленности в GCC, но никаких ошибок в Clang, я упростил код. Это видно ниже.

struct Foo
{
    // Foo(Foo&&) = delete;
    // Foo(const Foo&) = delete;
    Foo(int*) {}
};

struct Bar
{    
    template<typename T>
    operator T()
    {
        return Foo{nullptr};
    }
};

int main() { Foo f{Bar{}}; }

Ошибки заключаются в следующем.

main.cpp:17:18: error: call to constructor of 'Foo' is ambiguous
int main() { Foo f{Bar{}}; }
                 ^~~~~~~~
main.cpp:1:8: note: candidate is the implicit move constructor
struct Foo
       ^
main.cpp:1:8: note: candidate is the implicit copy constructor
main.cpp:5:1: note: candidate constructor
Foo(int*) {}
^

На этот раз я не смог сделать это успешно для Clang, поэтому я полагаю, что это была ошибка Clang, и это предполагаемое поведение.

Когда я явно удаляю копии и перемещаю конструкторы (т.е. раскомментирую верхние две строки кода), я вместо этого получаю

note: candidate constructor has been explicitly deleted

но все еще ошибка. Тогда как я могу пойти по поводу рассогласования строительства здесь?

Обратите внимание, что я специально добавил Foo{nullptr} вместо просто nullptr, но нет никакой разницы. То же самое с маркировкой Foo ctor. Эта ошибка неоднозначность возникает только тогда, когда Bar оператор преобразования шаблонных.

Я могу добавить SFINAE в оператор преобразования, но я не уверен, что я исключу. Например, это заставило бы его работать:

template<typename T, std::enable_if_t<std::is_same<T, Foo>{}>* = nullptr>

Это еще один, который я нашел, и это может быть моим ответом:

template<typename T, std::enable_if_t<!std::is_same<T, int*>{}>* = nullptr>

ОТВЕТЫ

Ответ 1

Чтобы устранить двусмысленность, добавьте explicit выражение в выражение оператора преобразования:

struct Bar
{    
    template<typename T>
    explicit operator T()
    {
        return Foo{nullptr}; 
    }
};

Почему это необходимо? Поскольку Foo имеет конструктор, принимающий int*, и поэтому operator int*() экземпляр operator T() шаблон рассматриваются как часть разрешения перегрузки для инициализации f. См. Раздел [over.match.copy]:

1 [...] Предполагая, что " cv1 T " - это тип инициализированного объекта, с типом типа T, выбранные функции выбираются следующим образом:

  • (1.1) Преобразующие конструкторы T являются функциями-кандидатами.

  • (1.2) Когда тип выражения инициализатора является типом класса " cv S ", рассматриваются неявные функции преобразования S и его базовые классы. При инициализации временного объекта ([class.mem]) привязывается к первому параметру конструктора, где параметр имеет тип "ссылка на возможно сгенерированный T " T и конструктор вызывается с одним аргументом в контексте прямая инициализация объекта типа " cv2 T ", также рассматриваются явные функции преобразования.

Из (1.2) следует, что для инициализации рассматриваются только функции неявного преобразования, поэтому двусмысленность - поскольку компилятор не может решить между построением f с использованием ссылки на Foo или, как уже упоминалось, с использованием int* (полученного путем copy-initializing) из возвращаемого значения operator int*. Однако, когда выражение инициализатора является временным объектом, мы также рассматриваем явные преобразования - но только если они соответствуют конструктору, ссылающемуся на Foo, наш "возможно, с квалификацией T ", то есть на наши конструкторы копирования и перемещения. Все это поведение согласуется с [class.conv.fct¶2]:

Функция преобразования может быть явной ([dcl.fct.spec]), и в этом случае она рассматривается только как пользовательское преобразование для прямой инициализации ([dcl.init]). В противном случае пользовательские преобразования не ограничены для использования в назначениях и инициализациях.

И так, говоря то же самое здесь в третий раз: если он не помечен как explicit, ничего не мешает компилятору попытаться скопировать-инициализировать int* который будет использоваться для построения.

Ответ 2

Мое лучшее предположение после некоторого копания: я получаю ту же ошибку со следующим кодом:

struct Foo { Foo(int*) {} };

struct Bar {    
   operator Foo(); // { return Foo{nullptr}; }
   /* explicit */ operator int*();
};

int main() { Foo f{Bar{}}; }

И, когда я раскомментирую прокомментированный код, проблема исчезает. Мне кажется, что в оригинальной шаблонной версии OP, когда неявное преобразование требуется от Bar to Foo, GCC только "создает экземпляры" деклараций операторов преобразования, а затем решает перегрузку перед созданием экземпляров своих тел.

Что касается того, почему explicit помогает, это происходит потому, что во втором случае требуется еще одно требуемое преобразование (Bar → int* а затем int* → Foo).