Странное поведение при использовании std::move shared_ptr с условным оператором

Поскольку второй и третий операнд условного оператора не относятся к одной и той же категории значений (т. е. std::move(ptr) — это значение x, а std::shared_ptr<int>(ptr) — значение pr), это условное выражение попадает под действие [expr.cond]/7:

Стандартные преобразования Lvalue-to-rvalue, массива в указатель и функции в указатель выполняются для второго и третьего операндов. После этих преобразований должно выполняться одно из следующих условий:

• Второй и третий операнды имеют одинаковый тип; результат имеет этот тип, и объект результата инициализируется с использованием выбранного операнда.
• [...]

std::shared_ptr<int>(ptr) уже является prvalue, поэтому преобразование lvalue в rvalue (которое на самом деле является преобразованием glvalue в prvalue) ничего с ним не делает.

std::move(ptr) преобразуется в значение prvalue, и это значение prvalue используется для инициализации объекта результата. Инициализация результирующего объекта использует конструктор перемещения (потому что это конструктор, который инициализирует std::shared_ptr<int> из значения x этого типа, что и есть std::move(ptr)). Конструктор перемещения «крадет» значение из ptr. Объект результата — это временный объект, который привязан к параметру a, а затем уничтожается. Обратите внимание, что все это происходит только в том случае, когда std::move(ptr) действительно оценивается (что требует, чтобы i == 9 было истинным).

Вызываемые функции C++ не обязаны перемещать значение, даже если они вызываются со ссылкой на rvalue. В частности, ваш func() даже не касается своего аргумента a, поэтому ptr остается неизменным в этом вызове: func(std::move(ptr)).

Наоборот, ваше выражение

func(i == 9 ? std::move(ptr) : std::shared_ptr<int>(ptr));

всегда создает временный тип std::shared_ptr<int> перед вызовом func() со ссылкой rvalue на этот временный объект. Что происходит под капотом:

{
    std::shared_ptr<int> temp = i == 9 ? std::move(ptr) : std::shared_ptr<int>(ptr));
    func(std::move(temp));
}

Когда i равно 9, задание temp = std::move(ptr) перемещает ptr в temp и оставляет ptr пустым. Затем, когда достигается конец блока и временное выходит за пределы области действия, оно уничтожается.

Вы можете избежать такого поведения, изменив свою строку на любой из следующих двух вариантов:

func(i == 9 ? std::move(ptr) : std::move(std::shared_ptr<int>(ptr)));

или:

func(std::move(i == 9 ? ptr : std::shared_ptr<int>(ptr)));

Оба варианта гарантируют, что созданное временное будет иметь ссылочный тип (а именно std::shared_ptr<int>&& в первом случае и std::shared_ptr<int>& во втором случае), поэтому ничего не нужно копировать.

Вы можете спросить, почему исходный код создает временный объект типа std::shared_ptr<int> (а не std::shared_ptr<int>&&). Ну, причина в хорошо известной оптимизации возвращаемого значения (RVO), которая была введена в C++ десятилетия назад: функции, которые возвращают объект, на самом деле вызываются таким образом, что вызывающая функция уже выделяет место для этого объекта и передает указатель к этому объекту к вызываемой функции. Затем вызываемая функция записывает возвращаемое значение непосредственно в это пространство. Из-за этого многие прямые назначения, такие как:

auto x = function(a, b, c);

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