rvalue и operator ->

[ssoft]

есть такая фраза: пьяный проспиццо, дурак - никогда(ц) Петр I

Ну хоть теперь ясно, с кем дело имеем .
Челом бьем).

твоя обертка со своим оператором 'стрелочка' косит под указатель.
не удивительно, что ты столкнулся с специфичным для указателей поведением.

Не обертка косит, а отсутствие оператора '.' заставляет использовать оператор '->' и мириться со специфичным для указателей поведением.

нет, не верно.
не нужно путать понятие "шаблон класса" и "шаблон функции".
...

Что ж, хотите, пишите так

Код

C++ (Qt)
struct Test
{
    void foo () && { ::std::cout << "Hello rvalue foo method." << ::std::endl; }
    void bar () && { ::std::cout << "Hello rvalue bar method." << ::std::endl; }
};
 

Код

C++ (Qt)
template<class T> struct wrapper
{
    T m_value;
 
    void exec () &&
    {
        ::std::move( m_value ).foo();
        ::std::move( m_value ).bar();
        // 100500 times using of ::std::move( m_value )
    }
};
 

вместо

Код

C++ (Qt)
template<class T> struct wrapper
{
    T m_value;
 
    void exec () &&
    {
        ::std::forward< T && >( m_value ).foo();
        ::std::forward< T && >( m_value ).bar();
    }
};
 

Даже отговаривать не буду)).

[ViTech]

В случае с std::forward экземпляр _Bers таки истину глаголит. На сколько я понимаю, вне контекста шаблонных аргументов функции(с forwarding references), std::forward особого смысла не имеет (ну разве что короче, чем static_cast). Правда, std::move тоже static_cast, так что с точки зрения реализации тут спорить особо не о чем .

[_Bers]

Код

C++ (Qt)
template<class T> struct wrapper
{
    T m_value;
    void exec () &&
    {
        ::std::forward< T && >( m_value ).foo();
        ::std::forward< T && >( m_value ).bar();
    }
};
 

Даже отговаривать не буду)).

Пётр I был чертовски прав.

[_Bers]

Правда, std::move тоже static_cast, так что с точки зрения реализации тут спорить особо не о чем .

точка зрения реализации - это вообще монопенисуальный фактор.
значение имеет дизайн использования.

std::move очень простым и недвусмысленным образом отражает намерения автора кода.

[ssoft]

В случае с std::forward экземпляр _Bers таки истину глаголит. На сколько я понимаю, вне контекста шаблонных аргументов функции(с forwarding references), std::forward особого смысла не имеет (ну разве что короче, чем static_cast). Правда, std::move тоже static_cast, так что с точки зрения реализации тут спорить особо не о чем .

Да, но в данном случае есть еще аргумент this, тип которого и указывается явно для метода (void exec () &&).
И forward и move по сути static_cast, но бесконечно перемещать объект для доступа к rvalue функциональности, как то некрасиво.

Да и при желании можно обобщить так

Код

C++ (Qt)
template<class T> struct wrapper
{
    T m_value;
 
    void exec () &
    {
        ::std::forward< T & >( m_value ).foo();
        ::std::forward< T & >( m_value ).bar();
    }
    void exec () const &&
    {
        ::std::forward< T const && >( m_value ).foo();
        ::std::forward< T const && >( m_value ).bar();
    }
    // ...
};
 

С move такой фокус не прокатит.

[_Bers]

С move такой фокус не прокатит.

и это совершенно правильно.
нельзя переместить неизменяемый объект.
он же неизменяемый, Карл!

сама хотелка совершить такое - это какой то бред далеко за гранью здравого смысла.

[ssoft]

С move такой фокус не прокатит.

и это совершенно правильно.
нельзя переместить неизменяемый объект.
он же неизменяемый, Карл!

сама хотелка совершить такое - это какой то бред далеко за гранью здравого смысла.

Ну хоть в чем то мы согласны), Карл!
Используйте forward, Карл, если нужно такое специфическое поведение, Карл!

[ViTech]

Да и при желании можно обобщить так

Код

C++ (Qt)
template<class T> struct wrapper
{
    T m_value;
 
    void exec () &
    {
        ::std::forward< T & >( m_value ).foo();
        ::std::forward< T && >( m_value ).bar();
    }
    void exec () const &&
    {
        ::std::forward< T const && >( m_value ).foo();
        ::std::forward< T const && >( m_value ).bar();
    }
};
 

Можно. А можно и так:

Код

C++ (Qt)
template<class T> struct wrapper
{
    T m_value;
 
    void exec () &
    {
        static_cast< T & >( m_value ).foo();
        static_cast< T && >( m_value ).bar();
    }
    void exec () const &&
    {
        static_cast< T const && >( m_value ).foo();
        static_cast< T const && >( m_value ).bar();
    }
};

Это если к семантике придираться . По смыслу, std::forward у меня больше ассоциируется с передачей аргумента функции куда-то дальше. Данный же случай больше похож на доступ к объекту, так что ни move ни forward особо не подходят, а выражается именно преобразование объекта к нужному типу.

[ssoft]

Это если к семантике придираться . По смыслу, std::forward у меня больше ассоциируется с передачей аргумента функции куда-то дальше. Данный же случай больше похож на доступ к объекту, так что ни move ни forward особо не подходят, а выражается именно преобразование объекта к нужному типу.

Так тоже семантически понятно).
А использование move может и с толку сбить. Перемещаем - перемещаем, переместить не можем).

[_Bers]

По смыслу, std::forward у меня больше ассоциируется с передачей аргумента функции куда-то дальше.

для этого он и был придуман.

Данный же случай больше похож на доступ к объекту, так что ни move ни forward особо не подходят, а выражается именно преобразование объекта к нужному типу.

просится что-то явно-говорящее:

Код:

access_to_temporary(m_value);

[_Bers]

Используйте forward, Карл, если нужно такое специфическое поведение, Карл!

оно нафиг не нужно, Карл!
нет разницы временный объект или нет, если он - константный, Карл!

[ViTech]

А использование move может и с толку сбить. Перемещаем - перемещаем, переместить не можем).

move тоже надо согласно смыслу употреблять, а не как в моём первом ответе . Я таким иногда грешу, когда лень static_cast писать.

А свершится перемещение или нет, также зависит и от принимающей стороны.

[Авварон]

move и _есть_ статик каст к T&&
forward - это статик каст к & или && зависимости от того, какой тип у аргумента (void foo(Type &&t); - t это lvalue, а не rvalue)
Но у меня вопрос, внутри && ф-ии мемберы же тоже lvalue, нет? И спор о семантике (мув или форвард) бесполезен, форвард просто ничего не сделает.
И второй вопрос - а это вообще ок переиспользовать мувнутый объект? foo() && может спокойно разрушить внутреннее состояние и bar() && отработает на пустом объекте

[ssoft]

Но у меня вопрос, внутри && ф-ии мемберы же тоже lvalue, нет? И спор о семантике (мув или форвард) бесполезен, форвард просто ничего не сделает.

Как ни странно, но внутри && функций мемберы lvalue, в то время как в случае доступа через оператор '.' rvalue.

Код

C++ (Qt)
wrapper< Test >().m_value; // rvalue
 

Пока не нашел объяснение, почему это так.
Стандарт регламентирует применение свойств rvalue/lvalue к членам класса, подобно классификаторам const, volatile.
Тем не менее, это не выполняется для методов &&, а для const, volatile выполняется).

И второй вопрос - а это вообще ок переиспользовать мувнутый объект? Улыбающийся foo() && может спокойно разрушить внутреннее состояние и bar() && отработает на пустом объекте

Реализация методов подобных foo() && преследуют ограничения возможности их вызова и ничего больше. Про разрушение речь не идет.

Код

C++ (Qt)
Test().foo(); // Ok
Test test;
test.foo(); // Error
static_cast< Test && >( test ).foo(); // Ok
 

move всего лишь подчеркивает намерение перемещения.

Код

C++ (Qt)
::std::move( value ).foo(); // что и куда перемещаем? что имеется в виду?
container.append( ::std::move( value ) ); // содержимое value перемешается в контейнер и, возможно, сам value некорректен.
 

[_Bers]

Но у меня вопрос, внутри && ф-ии мемберы же тоже lvalue, нет?

да.  
поскольку у этих мемберов есть имена.

попробую проиллюстрировать на примере:

Код:

//казалось бы, должна принимать любые объекты, имеющие тип int&& 
void foo(int&&) 
{}

int main()
{
    int&& v = std::move(10);

    // error: cannot bind ‘int’ lvalue to ‘int&&’
    foo(v);
}

казалось бы: типы совпадают, чего ему надо???
почему это rvalue-reference внезапно оказалась lvalue ?

потому что стандарт говорит:
временные объекты - это объекты, у которых нет имени.

Код:

// не просто выполняет преобразование к rvalue-reference
// она создает контекст, в рамках которого у xvalue нет имени
set_unigue( std::move(v) );