Какое время жизни у переменной?

Question

[Артур]

std::forward_list <T> copy_list(const std::forward_list<T>& in)
{
    auto out = in;
    out.reverse();
    return out;
}

Насколько я понимаю, переменная out, включая и то на что она ссылается, должно уничтожится и за ее пределами не должно быть возможности использовать эту ссылку и данные т.к. это все на стеке. Но, возвращенное ею значение печатается и им можно спокойно манипулировать. Почему?

Answer 1

[Евгений Шатунов]

auto out = in;
Тип переменной `out` будет `std::forward_list<T>`. [Пояснение 1], [Пояснение 2]

Поэтому `out ` будет локальной переменной и будет иметь локальное время жизни.
Исключением может быть только temporary lifetime extension. Тогда время жизни переменной продлится.

The lifetime of a temporary object may be extended by binding to a const lvalue reference or to an rvalue reference (since C++11), see reference initialization for details.

Comments

[Артур]

Получается, в любом случае вернется объект, а не ссылка. Как тогда вернуть ссылку из функции?

[Евгений Шатунов]

Артур , а зачем тебе возвращать ссылку на локальный объект у которого время жизни ограничено его локальным пространством? Ссылку-то ты вернешь, да объект к тому моменту уже будет разрушен.

Чаще всего возвращаемые по значению объекты перемещаются в принимающие результат функции места. Твой `out` будет возвращен по значению, но он не будет скопирован, а будет перемещен.
И это совсем не страшно, а наоборот - очень хорошо.

К тому же, есть Copy elision, благодаря которому объекта `out` в твоей функции и вовсе не будет, а все манипуляции будут производиться на том объекте, который примет результат функции `copy_list`.

[Артур]

Ну да, как раз перемещение мне и нужно. Мне просто интересен был механизм почему так. Вообще я думал что 'out' будет иметь тип std::forward_list&, а не сам объект. Для меня это открытие.
А на счет возврата по ссылке, это ради производительности, если возвращаемый будет довольно тяжелый. Он же сначала копируется при присваивании 'out = in', а потом еще раз во время ретёрна. Думал как можно углы срезать :) Но это, видимо, не лучшее решение.

[Евгений Шатунов]

Артур
В широком смысле слова auto - это зло и контрпродуктивно. Не стоит его использовать по каждому случаю.
Его резонно использовать только тогда, когда тип однозначно читается из всей конструкции
auto my_ptr = std::make_shared<MyType>();
или когда объявление типа становится уродским

std::map<std::string, std::vector<std::shared_ptr<std::pair<std::string, std::wstring>>>> uber_map;

auto found_item = uber_map.find( "foo" );

В твоем случае auto - лишний.
Но все равно. Если есть надобность написать именно auto и именно ссылку, то это надо писать прямо:
auto& out = in;

А если нет возможности явно определить ссылка там нужна или значение, но ссылка нужнее, то использовать стоит запись
decltype( auto ) out = in;

Он же сначала копируется при присваивании 'out = in'

Это верно.

а потом еще раз во время ретёрна

А это верно только если объект не может быть перемещен. Для перемещаемого объекта будет выполнено перемещение.

В 11м стандарте на счет срезания углов за тебя уже подумали. :)

[Артур]

Евгений Шатунов, Большое спасибо!

Answer 2

[Мария Мальцева]

В стеке отдельно резервируется место под возвращаемое функцией значение, и именно туда, а не по адресу переменной out, записывается результат через return. И, соответственно, дальше работа происходит именно по адресу с возращенным значением.

Answer 3

[zencd]

Переменная и её значение - разные вещи. У переменной ограниченное время жизни, scope. Значением же можно пользоваться и дальше потому что значение будет скопировано, вызовется copy constructor. Возможны оптимизации, но суть такая.