Повернення унікальних_ptr з функцій

unique_ptr<T>не дозволяє створювати копію, натомість підтримує семантику переміщення. Тим не менш, я можу повернути a unique_ptr<T>з функції і призначити повернене значення змінній.

#include <iostream>
#include <memory>

using namespace std;

unique_ptr<int> foo()
{
  unique_ptr<int> p( new int(10) );

  return p;                   // 1
  //return move( p );         // 2
}

int main()
{
  unique_ptr<int> p = foo();

  cout << *p << endl;
  return 0;
}

Код, описаний вище, складається і працює за призначенням. То як це, що цей рядок 1не викликає конструктор копій і призводить до помилок компілятора? Якщо б мені довелося використовувати рядок 2замість цього, це мало б сенс (також використовується лінія 2працює, але нам цього не потрібно).

Я знаю, що C ++ 0x дозволяє це виняток, unique_ptrоскільки значення повернення є тимчасовим об'єктом, який буде знищений, як тільки функція завершиться, гарантуючи тим самим унікальність повернутого покажчика. Мені цікаво, як це реалізується, чи це спеціальний вміст у компіляторі чи є якийсь інший пункт у мовній специфікації, який це використовує?

Чи є якийсь інший пункт у мовній специфікації, який це використовує?

Так, див. 12.8 §34 та §35:

Коли певні критерії виконуються, реалізація дозволена опускати конструкцію копіювання / переміщення об'єкта класу [...] Це елісія операцій копіювання / переміщення, що називається копіюванням elision , дозволено [...] у звіті про повернення у функція з типом повернення класу, коли вираз - це ім'я енергонезалежного автоматичного об'єкта з тим же cv-некваліфікованим типом, що і тип повернення функції [...]

Коли критерії елісії операції копіювання виконуються і об'єкт, який потрібно скопіювати, позначається рівнем значення, спочатку роздільна здатність перевантаження для вибору конструктора для копії виконується так, як ніби об'єкт був позначений рівнем .

Просто хотілося додати ще один пункт, що повернення за значенням має бути вибором за замовчуванням тут, оскільки в найгіршому випадку називається значення у операторі return, тобто без елісій у C ++ 11, C ++ 14 та C ++ 17. як ревальва. Так, наприклад, наступна функція компілюється з -fno-elide-constructorsпрапором

std::unique_ptr<int> get_unique() {
  auto ptr = std::unique_ptr<int>{new int{2}}; // <- 1
  return ptr; // <- 2, moved into the to be returned unique_ptr
}

...

auto int_uptr = get_unique(); // <- 3

З встановленим прапором на компіляції в цій функції відбуваються два ходи (1 і 2), а потім - наступний хід (3).

Це жодним чином не std::unique_ptrстосується, але стосується будь-якого класу, який є рухомим. Це гарантується мовними правилами, оскільки ви повертаєтесь за значенням. Компілятор намагається схилити копії, викликає конструктор переміщення, якщо він не може видалити копії, викликає конструктор копій, якщо він не може переміститися, і не може компілювати, якщо він не може скопіювати.

Якби у вас була функція, яка приймає std::unique_ptrяк аргумент, ви б не змогли передати їй p. Вам доведеться явно викликати конструктор переміщення, але в цьому випадку ви не повинні використовувати змінну p після виклику до bar().

void bar(std::unique_ptr<int> p)
{
    // ...
}

int main()
{
    unique_ptr<int> p = foo();
    bar(p); // error, can't implicitly invoke move constructor on lvalue
    bar(std::move(p)); // OK but don't use p afterwards
    return 0;
}

У унікального_ptr немає традиційного конструктора копій. Натомість у нього є "конструктор переміщення", який використовує посилання rvalue:

unique_ptr::unique_ptr(unique_ptr && src);

Посилання на рецензію (подвійний амперсанд) прив'язуватиметься до рейтингу. Ось чому ви отримуєте помилку під час спроби передати lvalue unique_ptr функції. З іншого боку, значення, яке повертається з функції, трактується як значення, тому конструктор переміщення викликається автоматично.

До речі, це спрацює правильно:

bar(unique_ptr<int>(new int(44));

Тимчасовий jedinstveний_птр тут - рецензія.

Я думаю, що це ідеально пояснено в пункті 25 « Ефективний сучасний C ++» Скотта Майєрса . Ось уривок:

Частина Стандарту, що благословляє RVO, продовжує говорити, що якщо умови для RVO дотримані, але компілятори вирішили не виконувати копіювання елісії, об'єкт, що повертається, повинен розглядатися як реальне значення. Насправді, Стандарт вимагає, що коли дозволено RVO, відбувається або копіювання елісії, або std::moveзастосовано неявно до повернених локальних об'єктів.

Тут RVO посилається на оптимізацію повернутого значення , і якщо умови для RVO виконуються, означає повернути локальний об'єкт, оголошений всередині функції, яку ви очікували б виконати RVO , що також добре пояснено в пункті 25 його книги, посилаючись на стандарт (сюди локальний об'єкт включає тимчасові об'єкти, створені оператором return). Найбільше відірванняstd::move уривку - це або елісія копії відбувається, або неявно застосовується до повернених локальних об'єктів . Скотт у пункті 25 зазначає, щоstd::move неявно застосовується, коли компілятор вирішить не ухилятись від копії, а програміст не повинен це робити.

У вашому випадку код, очевидно, є кандидатом на RVO, оскільки він повертає локальний об'єкт, pа тип такого pж типу, що повертається, що призводить до копіювання елісії. І якщо компілятор вирішить не ухилятись від копії, то з будь-якої причини запустив std::moveби рядок 1.

Одне, чого я не бачив в інших відповідях, цеЩоб уточнити ще одну відповідь, що існує різниця між поверненням std :: unique_ptr, який був створений у межах функції, і тим, який був наданий цій функції.

Приклад може бути таким:

class Test
{int i;};
std::unique_ptr<Test> foo1()
{
    std::unique_ptr<Test> res(new Test);
    return res;
}
std::unique_ptr<Test> foo2(std::unique_ptr<Test>&& t)
{
    // return t;  // this will produce an error!
    return std::move(t);
}

//...
auto test1=foo1();
auto test2=foo2(std::unique_ptr<Test>(new Test));