Чи є випадки, коли повернення посилання на RValue (&&) є корисним?

Чи є причина, коли функція повинна повертати посилання RValue ? Техніка, або фокус, або ідіома чи шаблон?

MyClass&& func( ... );

Я усвідомлюю небезпеку повернення посилань загалом, але іноді ми все одно робимо це, чи не так? T& T::operator=(T)це лише один ідіоматичний приклад. Але як щодо T&& func(...)? Чи є загальне місце, де ми могли б отримати від цього? Можливо, інакше, коли хтось пише бібліотеку або код API, порівняно із кодом клієнта?

Є кілька випадків, коли це доречно, але вони відносно рідкісні. Випадок наводиться в одному прикладі, коли ви хочете дозволити клієнту перейти від члена даних. Наприклад:

template <class Iter>
class move_iterator
{
private:
    Iter i_;
public:
    ...
    value_type&& operator*() const {return std::move(*i_);}
    ...
};

Це випливає з коментаря towi. Ви ніколи не хочете повертати посилання на локальні змінні. Але у вас може бути таке:

vector<N> operator+(const vector<N>& x1, const vector<N>& x2) { vector<N> x3 = x1; x3 += x2; return x3; }
vector<N>&& operator+(const vector<N>& x1, vector<N>&& x2)    { x2 += x1; return std::move(x2); }
vector<N>&& operator+(vector<N>&& x1, const vector<N>& x2)    { x1 += x2; return std::move(x1); }
vector<N>&& operator+(vector<N>&& x1, vector<N>&& x2)         { x1 += x2; return std::move(x1); }

Це повинно запобігти будь-яким копіям (і можливим розподілам) у всіх випадках, крім випадків, коли обидва параметри є значеннями l.

Ні. Просто поверніть значення. Повернення посилань загалом зовсім не небезпечне - це повернення посилань на локальні змінні, що є небезпечним. Повернення посилання на rvalue, однак, майже ні до чого майже в усіх ситуаціях (я думаю, якщо ви писали std::moveчи щось інше).

Ви можете повернутися за посиланням, якщо впевнені, що об’єкт, на який посилається, не вийде за межі обсягу після виходу функції, наприклад, це посилання на глобальний об’єкт або функція-член, що повертає посилання на поля класу тощо.

Це правило повернення посилання однаково для посилань lvalue та rvalue. Різниця полягає в тому, як ви хочете використовувати повернене посилання. Як я бачу, повернення за посиланням rvalue є рідкістю. Якщо у вас є функція:

Type&& func();

Вам не сподобається такий код:

Type&& ref_a = func();

оскільки він фактично визначає ref_a як Type &, оскільки іменоване посилання rvalue є значенням, і фактичний рух тут виконуватися не буде. Це схоже на:

const Type& ref_a = func();

за винятком того, що фактичний ref_a є посиланням, яке не є const lvalue.

І це також не дуже корисно, навіть якщо ви безпосередньо передаєте func () іншій функції, яка приймає аргумент Type &&, оскільки вона все ще є іменованим посиланням всередині цієї функції.

void anotherFunc(Type&& t) {
  // t is a named reference
}
anotherFunc(func());

Відносини func () та anotherFunc () більше схожі на "авторизацію", згідно з якою func () погоджується, що anotherFunc () може взяти у власність (або можна сказати "вкрасти") повернутий об'єкт із func (). Але ця угода дуже вільна. Недоступне посилання lvalue все ще може бути "викрадено" абонентами. Насправді функції рідко визначаються для прийняття аргументів посилання rvalue. Найпоширеніший випадок, що "anotherFunc" - це назва класу, а anotherFunc () - насправді конструктор переміщення.

Ще один можливий випадок: коли вам потрібно розпакувати кортеж і передати значення функції.

Це може бути корисно в цьому випадку, якщо ви не впевнені в копіюванні.

Такий приклад:

template<typename ... Args>
class store_args{
    public:
        std::tuple<Args...> args;

        template<typename Functor, size_t ... Indices>
        decltype(auto) apply_helper(Functor &&f, std::integer_sequence<size_t, Indices...>&&){
            return std::move(f(std::forward<Args>(std::get<Indices>(args))...));
        }

        template<typename Functor>
        auto apply(Functor &&f){
            return apply_helper(std::move(f), std::make_index_sequence<sizeof...(Args)>{});
        }
};

досить рідкісний випадок, якщо ви не пишете якусь форму std::bindабо std::threadзаміну.