auto&& mytup = std::make_tuple(9,1,"hello");
std::get<0>(mytup) = 42;
cout << std::get<0>(mytup) << endl;
auto&& var =
func() вместо auto var = func(), чтобы не было копирования/перемещения?да. Любой возврат из функции, которая не возвращает ссылочный тип, может включать копирование/перемещение. Устранение вот что такое RVO. Объект, к которому привязана ваша ссылка, должен быть каким-то образом инициализирован.
Нет, зачем? Время жизни временного/prvalue, привязанного к ссылке, определяется областью действия ссылки.
Если func() не возвращает ссылочный тип, не должно быть никакой разницы в эффективности (и в поведении)
между
auto&& var = func();
и
auto var = func();
В обоих случаях создается объект со временем жизни до конца содержащего его блока. В одном случае он имеет собственное имя, в другом — по ссылке. В обоих случаях имя может использоваться как lvalue. RVO можно одинаково хорошо применять в любом случае.
Некоторые компиляторы могут оптимизировать оптимизацию для локального объекта лучше, чем для ссылки, даже несмотря на то, что в данном случае ссылка на временную на самом деле ничем не отличается от локального объекта.
Если func() может возвращать ссылку, все обстоит иначе - в этом случае вы должны решить, хотите ли вы копировать/перемещать или нет.
Foo& func(), версия auto&& не будет копироваться, а auto будет копироваться.
- person balki; 13.02.2013
Это всегда проблематично только в том случае, когда инициализатор является вызовом функции, который возвращает недолговечную ссылку rvalue. Меньше слов и больше кода:
// Fine; lifetime extension applies!
auto&& ref = 42;
auto id = [](int&& i) -> int&& { return std::move(i); };
auto&& uhoh = id(42);
// uhoh is now a stale reference; can't touch it!
Напротив, auto uhoh = id(42); сработало бы нормально.
В вашем случае, поскольку std::make_tuple возвращает значение, а не ссылку на rvalue, проблем нет.
Я придерживаюсь мнения, что реальная опасность исходит от тех функций и шаблонов функций со ссылочными параметрами rvalue, которые возвращают ссылку rvalue на те из некоторых подобъектов, от которых зависит время жизни. (При этом такая простая вещь, как auto&& ref = std::move(42);, демонстрирует проблему!)
Ситуация не совсем нова для C++11, учтите: T const& ref = bar(T_factory());.
T const& pass(T const& t) { return t; }, когда пытался улучшить обнаружение Clang возвращаемых ссылок на временные файлы... жаль, что для обнаружения возможных проблем требуется межпроцедурный анализ: x
- person Matthieu M.; 13.02.2013
В C++ (даже до C++11) существует специальное правило, согласно которому, если вы привязываете ссылку к временному объекту, время жизни временного объекта будет продлено до времени существования ссылки.
Более простой случай:
int foo () {
return 42;
}
int bar () {
const int& x = foo();
return x; // Here is safe to use x
}
Результатом оценки вызова make_tuple является временное значение prvalue экземпляра tuple. спецификатор типа auto будет выведен как тот же экземпляр tuple (7.1.6.4p6), поэтому mytup имеет тип tuple<...> &&. Затем временное значение prvalue продлевается на весь срок службы ссылкой mytup (12.2p5).
make_tuple все еще может быть RVO).mytup будет рассматриваться как lvalue, даже если его тип является ссылкой на rvalue. Однако нет смысла использовать auto &&, так как все разумные компиляторы исключат копирование/перемещение из временного.Чтобы уточнить, единственный способ рассматривать mytup как значение r — использовать std::forward<decltype(mytup)>(mytup), как в What сообщает ли нам auto&&?; однако, если вы знаете тип mytup (в данном случае tuple<...>), вы также можете использовать std::move.
auto&& var = func(), stackoverflow.com/questions/13618506/ - person billz schedule 13.02.2013const int & foo() { return 42; } int i = foo();иint foo() { return 42; } const int & i = foo();- это одни и те же ситуации (это не так). - person Luc Touraille schedule 13.02.2013