В примере
тоже присутствует имя m_value, но это всё rvalue значения.
тёмная сторона с++.
мир тонких граблей, двусмысленных трактовок,
и поведений у различных компиляторов ждут отважного путешественника
на этой стязе.
простой пример:
известный факт: константная ссылка на временный объект подливает время его жизни
до конца жизни самой ссылки.
https://ideone.com/mKHcSL#include <iostream>
struct data
{
~data() { std::cout << "data: destructor\n"; }
};
int main()
{
std::cout << "begin...\n";
{
const auto& ref = data{};
std::cout << "work with temporary...\n";
}
std::cout << "finished!\n";
}
но что будет, если мы возьмем константную ссылочку не на весь агрегат,
а только на какой то один из мемберов?
#include <iostream>
struct data
{
~data() { std::cout << "data: destructor\n"; }
};
struct sample
{
data value;
~sample() { std::cout << "sample: destructor\n"; }
};
int main()
{
std::cout << "begin...\n";
{
const auto& ref = sample().value;
std::cout << "work with temporary...\n";
}
std::cout << "finished!\n";
}
вывод в консоль:
begin...
work with temporary...
sample: destructor
data: destructor
finished!
продлевается жизнь всего агрегата.
отлично! - скажешь ты, - это логично.
раз время жизни мембера продлевается,
тогда нужно продлить время жизни и всего агрегата,
ведь без хозяина мембер существовать не может.
теперь оставляем в классе хозяине только POD-типы мемберов:
#include <iostream>
struct data
{
~data() { std::cout << "data: destructor\n"; }
};
struct sample
{
//data value;
int value;
~sample() { std::cout << "sample: destructor\n"; }
};
int main()
{
std::cout << "begin...\n";
{
const auto& ref = sample().value;
std::cout << "work with temporary...\n";
}
std::cout << "finished!\n";
}
вывод в консоль:
begin...
sample: destructor
work with temporary...
finished!
и о боже! деструктор агрегата отработал раньше, чем закончилось время жизни константной ссылки!
в этом случае мы получаем протухшую ссылку.
привет багам!
что примечательно:
на разных компиляторах с разными настройками оптимизации можно получить разные результаты.
вывод:
ну его нафиг: связываться с "временными мемберами".
практика показывает:
не нужно здесь искать какую то логику, и на что либо закладываться.
И, еще отмечу, что move без потребителя не является перемещением, отсюда и появилась моя первоначальная ремарка (
здесь).
строго говоря, само название "move" не вполне, казалось бы, отражает свою функцию.
факт перемещения следует из контекста применения мува,
но не содержится в самом муве.
для чего вы хотите задействовать методы временного объекта?
какие вообще плюшки вы хотите поиметь таким образом?
на самом деле единственная плюшка временного объекта - факт, что он временный.
а значит его можно переместить.
во всех остальных случаях его "временность" не имеет никакого значения.
отсюда прямиком вытекает:
вам не нужен метод временного объекта только для доступа к мемберу агрегата.
такой метод нужен либо для того, что бы можно было переместить мембер,
либо не нужен вовсе.
