Вроде ж нет? Сгенерённый move assignment operator подходит идеально и должен он выбираться, если я правильно понял, что там происходит.
А в строке 68 зачем явно указывать тип? Оно же его и так автоматически выберет по lvalue (полю .buffer)
Имеешь ввиду, можно фигурные скобки оставить?
именно 68: .buffer = {}, вместо .buffer = vk::Buffer{},
Это тоже хороший вариант, если нужно построить дефолтный объект
Тогда, если есть диспатч выводимого типа по типу rhs (не знаю, есть ли), то он не сработает нужным мне образом
Как я понимаю: Там есть три перегруженных operator= : неявные copy/move assignment vk::DescriptorBufferInfo и оператор присваивания, который принимает VkDescriptorBufferInfo const&. Дальше, конструкция { .buffer = vk::Buffer{} } может быть интерпретирована и как создание vk::DescriptorBufferInfo, и как создание VkDescriptorBufferInfo (после неявного вызова vk::Buffer::operator VkBuffer()). В обоих случаях у нас справа от = получается prvalue. Дальше, implicitly-declared move assignment operator идеально подходит для prvalue типа vk::DescriptorBufferInfo, для implicitly-declared copy assignment operator нужна привязка const& к prvalue, а для явно написанного оператора присваивания требуется и конверсия буффера в VkBuffer, и привязка const& к prvalue.
Кстати, если заменить на { .buffer = VkBuffer{} }, то картина точно такая же, как ни странно. Надо стандарт почитать.
там кажется проблема вообще не в .buffer =
Обсуждают сегодня