Продление жизни временных значений в С++: рецепты и подводные камни

в 12:20, , рубрики: auto, c++, c++11, C++14, decltype, l-value reference, nrvo, rvalue reference, temporary object, xvalue, Программирование, с++17

Прочитав эту статью вы узнаете:

  1. Способы, которыми можно продлить время жизни временного объекта в С++.

  2. Рекомендации и подводные камни этого механизма, с которыми может столкнуться С++ программист, и с которыми сталкивался на работе я.

Информация из статьи может быть полезна как новичкам, так и профессионалам.

Если заинтересовало, то самое время налить чая, и погнали разбираться где тут референсы повисли.

Оглавление

Они на деревьях, Джонни!

Для начала давайте обозначим набор проблем, которые вероятнее всего могут встретиться при обращении со ссылками:

  1. Висячие ссылки.

  2. Всё.

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

Для тех кто не знает, висячая ссылка(dangling reference) - это ссылка на область памяти, в которой нет "живого" объекта. Это возможно когда время жизни ссылки дольше чем время жизни объекта, на который она указывает. Ссылка становится висячей в тот момент, когда компилятор разрушает объект(вызывает деструктор объекта и потом освобождает память, которая объектом занималась), а ссылку ещё нет.

Скрытая правда: как на самом деле появляются висячие ссылки
Скрытая правда: как на самом деле появляются висячие ссылки

Опасность висячей ссылки в том, что если кто-нибудь в это время воспользуется данной ссылкой, то может произойти всё что угодно, что описывается стандартом как неопределённое поведение или UB.

Что значит неопределённое? Если оно произойдёт то может случиться коллапс?

Неопределённым оно является относительно стандарта, а не вообще, то есть стандарт не описывает что конкретно должно произойти. На самом же деле результат зависит от самой программы, то есть от:

  1. Реализованного алгоритма.

  2. Используемого компилятора.

  3. Имплементации стандартной библиотеки.

  4. Накрученных при компиляции оптимизаций.

  5. Операционной системы и т.д.

Поэтому, теоретически, мы можем предполагать что же произойдёт(может ничего плохого и не произойдёт, а может и упасть программа).

Хоть теоретически мы и можем предполагать что произойдёт в том или ином случае, провоцирующем UB, но что бы вы выбрали: расследовать убийство, или не допускать его? Намного важнее - научиться избегать UB в своих программах, потому что программа с неопределённым поведением - горе для заказчика, а горе заказчика - наше горе.

Один из спонсоров появления висячих ссылок - нюансы механизма продления времени жизни временных объектов. Данный механизм существует с C++03(продление через константные lvalue ссылки). В C++11 его доработали(добавили rvalue ссылки) и он стал звучать так:

Если вы приняли временный объект по константной lvalue ссылке или rvalue ссылкe, то его время жизни будет продлено до времени жизни ссылки.

Исходя из этого утверждения можно заключить, что продление жизни работает только для временных объектов, на которые указывают ссылки. А ещё, если прибавить к этому определению сохранение по значению, то получается следующий список:

  1. Создание константной lvalue ссылки на временное значение.

  2. Создание rvalue ссылки на временное значение.

  3. Сохранение по значению.

Хотя, с точки зрения языка, сохранение по значению - не механизм продления жизни, поскольку временное значение в таком случае должно скопироваться или переместится(время жизни оригинального временного значения при этом не продлевается). Но, забегая вперёд:
1. Оптимизация copy elision приводит ко внешне похожим эффектам, как при сохранении по ссылке.
2. Сохранение по значению тоже имеет нюансы, связанные с продлением времени жизни через ссылки.

Давайте теперь поговорим про каждый из этих вариантов поподробнее. Но сперва рассмотрим класс Xray, при помощи которого мы будем отслеживать порядок вызова конструкторов и деструкторов.

Класс Xray
struct Xray
{
  Xray(std::string value)
    : mValue(std::move(value))
  {
      std::cout << "Xray ctor, value is " << mValue << std::endl;
  }
  
  Xray(Xray&& other)
    : mValue(std::move(other.mValue))
  {
      std::cout << "Xray&& ctor, value is " << mValue << std::endl;
  }
  
  Xray(const Xray& other)
    : mValue(other.mValue)
  {
      std::cout << "Xray const& ctor, value is " << mValue << std::endl;
  }
  
  ~Xray()
  {
      std::cout << "~Xray dtor, value is " << mValue << std::endl;
  }
  
  std::string mValue;
};

1. Способы продления времени жизни и сохранения временных значений

Продление жизни временных значений в С++: рецепты и подводные камни - 2

Для разогрева начнём с самого простого варианта: ситуации, в которой мы вообще не сохраняем временное значение, а только создаем его.

Если мы так сделаем, то компилятор по своему усмотрению решит когда ему лучше всего разрушить временный объект, он может сделать это в в любое время до выхода из тела main, либо же при выходе, но обязательно только после создания самого объекта. Пример на godbolt:

void main()
{
	// Вывод: Xray ctor, value is 1
	Xray{"1"}; 
  
	// Деструктор может быть вызван здесь(в т.ч. между вызовом операторов <<)
	std::cout << "Wait a sec" << std::endl;
	// Или деструктор может быть вызван здесь(в т.ч. между вызовом операторов <<)
	std::cout << "22 is " << 22 << std::endl;
  
} // Или деструктор может быть вызван здесь

1.1 Константная lvalue ссылка

Что такое lvalue ссылка?

Левосторонние ссылки(lvalue references)  - ссылки вида: Xray& и const Xray& (тип не обязательно должен быть Xray, можно и любой другой, например int). Левосторонняя ссылка всегда ссылается только на именованные, в некотором смысле постоянные значения(более подробно разберём этот вопрос в сравнении с rvalue ссылками).

Понять что ссылка левосторонняя можно по её типу(const T&, T&), либо же так: значения на которые она ссылается всегда находятся слева от = при объявлении переменной:

int i = 3;
int& iRef = i;

Здесь i - lvalue, поэтому и ссылка на него iRef называется lvalue reference.

Теперь же рассмотрим вариант с созданием константной lvalue ссылки на временный объект:

void main()
{
  // Вывод: Xray ctor, value is 1
  const Xray& xrayRef = Xray{"1"}; 
  
  // Вывод: xrayRef value is 1
  std::cout << "xrayRef value is " << xrayRef.mValue << std::endl;
  
} // Вывод: Xray dtor, value is 1

Всё чисто и просто: мы создаём временное значение при помощи Xray{"1"} и сохраняем константную ссылку на него в xrayRef. После чего временное значение разрушается при выходе из функции main(после достижения потоком исполнения программы конца тела функции - фигурной скобки } ).

Аналогично работает и следующий пример, за исключением того, что теперь при создании временного объекта произойдёт неявное преобразование типа из std::string в Xray:

void main()
{
  // Вывод: Xray ctor, value is 1
  const Xray& xrayRef = std::string("1"); 
} // Вывод: Xray dtor, value is 1
Почему компиляция этого примера не завершается ошибкой компиляции?

Данное преобразование не является ошибочным потому что в Xray объявлен конструктор, принимающий const std::string&, и по умолчанию все конструкторы разрешают неявные преобразования.

При желании мы можем запретить неявное приведение типов, если пометим конструктор Xray(const std::string&) как explicit, в таком случае нам нужно будет явно вызывать конструктор Xray{std::string("1")}.

Плюс такого подхода - нет лишних вызовов конструкторов копирования. Но в этом плане это не единственный способ, обладающий таким плюсом.

1.2 rvalue ссылка

Что означает правосторонняя ссылка и как она отличается от левосторонней?

Правосторонняя ссылка, это ссылка вида: Xray&& (тип не обязательно должен быть Xray, можно и любой другой, например int). Данный вид ссылки может указывать только на временные значения. Правосторонней же она называется потому что временные значения, на которые она указывает, всегда находятся справа от= при объявлении переменной:

int&& iRvalueRef = 3;

Здесь (int)3 - rvalue(временное значение), поэтому и ссылка на него iRvalueRef называется rvalue reference.

Отличия между rvalue и lvalue

Чтобы разобраться в отличиях, давайте рассмотрим пример:

int three = 3; 
int& threeLvalueRef = three;
int&& fourRvalueRef = 4;

Здесь:
1. (int)3 и (int)4 - rvalue, временные значения. У данных значений нет имени, по которому к ним можно обратиться.
2. int three - lvalue. У неё есть имя ‘three’, по которому к ней можно обратиться.
3. int& threeLvalueRef - lvalue reference. Она ссылается на lvalue three.
4. int&& fourRvalueRef - rvalue reference. Она ссылается на rvalue (int)3.

Более подробно про виды ссылок и их различия также можно прочитать в статьях:

  1. [RU] @rhaport Понимание lvalue и rvalue в C и С++

  2. [ENG] fluentcpp Understanding lvalues, rvalues and their references

Что такое семантика перемещения и как с ней связан std::move?

rvalue reference так же можно принять переместив объект(если в классе такого типа реализован конструктор перемещения, как в Xray::Xray(Xray&&)). Для этого нужно вызвать std::move:

Xray xray = Xray{‘123”};
Xray&& xrayRef = std::move(xray);

Сам std::move не занимается какой-то магией, он только приводит тип аргумента Xray к типу правосторонней ссылки Xray&&, чтобы таким образом, вызвался конструктор с параметром Xray&&, который называется конструктором перемещения, и в котором программист должен описать логику: какие поля класса нужно переместить и как.
А нужно это потому что существуют тяжеловесные типы, значения которых лучше перемещать, чем копировать.
Пример: скопировать значение строки Xray::mValue из одного места в другое - не лучший выбор, поскольку это подразумевает:

  1. Выделение, обычно, не маленького куска памяти размером mValue.size() байт.

  2. Побайтовое копирование значения каждого байта.

Такое копирование может быть очень долгим, ведь строка может быть длинной и в 10000 символов(и больше). Поэтому переместить её значение будет намного быстрее, в таком случае указатель на данные(const char*), хранящийся под капотом std::string, просто будет отдан другому экземпляру std::string, без всяких дополнительных аллокаций памяти и копирования значений байт.

Упрощённая реализация std::move для lvalue значений:

template<typename T>
T&& move(T& value) 
{
	return (T&&)value;
}

rvalue ссылка тоже подходит, если нужно ссылаться на временное значение, при этом не будет вызвано никаких дополнительных конструкторов перемещения или копирования:

void main()
{
  // Вывод: Xray ctor, value is 1
  Xray&& xrayRef = Xray{"1"};
} // Вывод: Xray dtor, value is 1

1.3 Сохранение по значению

Сохранение по значению выглядит следующим образом:

void main()
{
  // Вывод: Xray ctor, value is 1
  Xray xray = Xray{"1"}; 
} // Вывод: Xray dtor, value is 1

Возможно, глядя на этот пример у вас возникает вопрос: "Разве не будет вызова копирующего конструктора?".

Дело в том, что благодаря оптимизации copy elision, предотвращающей избыточное копирование, конструктор копирования/перемещения вызван не будет. И более того, даже в таком виде, будет вызван всего 1 конструктор(который создает объект Xray):

void main()
{
  // Вывод: Xray ctor, value is 1
  Xray xray = Xray{Xray{Xray{"1"}}}; 
} // Вывод: Xray dtor, value is 1

В С++ оптимизация copy elision появилась начиная с С++98, но поддерживалась не во всех компиляторах. Когда пришёл С++17, он навел порядок, и, начиная с него, все компиляторы обязаны поддерживать эту оптимизацию.

2. Выведение типов компилятором (type deduction)

Продление жизни временных значений в С++: рецепты и подводные камни - 3

В С++ существуют механизмы, которые позволяют нам самим не определять тип переменной, или определять его только частично. В таком случае компилятор, если это возможно, выведет тип самостоятельно, на основе инициализатора(присваиваемого выражения).

Хоть механизмы выведения типа отвечают только за способ выведения типа, и в конце концов выводят тип как ссылку или безссылочный тип(это означает, что при их использовании мы в конце концов всё равно приходим к одному из способов из п.1: либо к передаче по ссылке, либо к передаче по значению). Но для полноты картины их стоит рассмотреть, хотя бы вкратце.

Далее, для проверки того какой же именно компилятор вывел тип, можно воспользоваться бесплатным сервисом - cppinsights.

2.1 auto

Начиная с С++11 у нас появилась возможность использовать ключевое слово auto для выведения типа переменной через её инициализатор. Если мы используем его без дополнительных квалификаторов и &(as is), то при выведении типа переменной будут проигнорированы ссылочность и квалификаторы const, volatile. Это означает, что произойдёт сохранение по значению. Смотрите вывод типов на cppinsights:

void main()
{
  // Вывод: Xray ctor, value is 1
  auto xray = Xray{"1"}; // type = Xray
} // Вывод: Xray dtor, value is 1
Примеры отбрасывания квалификаторов при выведении через auto

Смотрите вывод типов на cppinsights:

int i = 0;
int& iRef = i;
const int& iConstRef = i;
volatile int& iVolatileRef = i;
const volatile int& iCVRef = i;
int* iPtr = &i;

auto _1 = i;             // type = int
auto _2 = iRef ;         // type = int
auto _3 = iConstRef ;    // type = int
auto _4 = iVolatileRef ; // type = int
auto _5 = iCVRef;        // type = int
auto _6 = iPtr ;         // type = int*

Чтобы добавить квалификаторы и ссылочность(или сохранить их при выводе типа) нужно указать их рядом с auto. При их добавлении в данном случае произойдет продление жизни через константную lvalue ссылку (cppinsights):

void main()
{
  // Вывод: Xray ctor, value is 1
  const auto& xray = Xray{"1"}; // type = const Xray&
} // Вывод: Xray dtor, value is 1

Также есть возможность указать auto&&, тогда механизм вывода будет очень похож на perfect forwarding. При его использовании в данном случае произойдет продление жизни через rvalue ссылку(cppinsights):

void main()
{
  // Вывод: Xray ctor, value is 1
  auto&& xray = Xray{"1"}; // type = Xray&&
} // Вывод: Xray dtor, value is 1

Чтобы узнать что такое perfect forwarding смотрите в п.2.4 template и информации по ссылкам указанным там. 

Примеры вывода типа через auto&&

Смотрите вывод типов на cppinsights:

int i = 0;
const int& iConstRef = i;

auto&& _ = i;           // type = int&
auto&& _1 = iConstRef ; // type = const int&
auto&& _2 = 4;          // type = int&&

2.2 decltype

С++11 принёс нам ключевое слово decltype, которое позволяет получить тип переданного ему выражения в compile time. Примеры вывода типов с использованием decltype на cppinsights:

int i = 0;
const int& iConstRef = i;
int&& iRvalueRef = 1;

decltype(i) _1 =  i;                             // type = int
decltype(iConstRef ) _2 =  iConstRef;            // type = const int&
decltype(iRvalueRef) _3 = std::move(iRvalueRef); // type = int&&
decltype(3) _4 = 3;                              // type = int

При его использовании в данном случае произойдет сохранение по значению:

void main()
{
  // Вывод: Xray ctor, value is 1
  decltype(Xray{"1"}) xray = Xray{"1"}; // type = Xray
} // Вывод: Xray dtor, value is 1

Если вам при этом нужно вывести тип объекта у которого нет нужного конструктора(или конструктора по умолчанию), то можно воспользоваться std::declval:

decltype(std::declval<Xray>()) xray = Xray{"1"}; // type = Xray&&

То, что вычисление типа происходит в compile time означает, что компилятор не вычисляет переданное в decltype выражение, в только смотрит на то какой тип получается в результате его вычисления.

При этом вы вероятно заметили, что использовать decltype в таком виде неудобно:
1. Появляется много лишней информации, которая полностью или частично дублирует присваиваемое выражение.
2. Иногда приходится использовать воркэраунды(вроде std::declval) чтобы вывести тип.

Видимо по этим причинам, в следующем стандарте этот механизм доработали и выдали нам decltype(auto).

2.3 decltype(auto)

Начиная с С++14 у нас появилась возможность передавать как параметр в decltype  ключевое слово auto. decltype(auto) позволяет вывести ровно такой-же тип, как у присваиваемого выражения, то есть ссылочность и квалификаторы при таком выводе будут сохранены.
Примеры вывода типов с использованием decltype(auto) на cppinsights:

int i = 2;
const int& iConstRef = 0;

decltype(auto) _1 = 1;            // type = int
decltype(auto) _2 = iConstRef;    // type = const int&
decltype(auto) _3 = std::move(i); // type = int&&

При его использовании в данном случае произойдёт сохранение по значению(cppinsights):

void main()
{
  // Вывод: Xray ctor, value is 1
  decltype(auto) xray = Xray{"1"}; // type = Xray
} // Вывод: Xray dtor, value is 1

2.4 template

Выведение типа через шаблон очень похоже на выведение типа через auto, и наоборот.

Если мы используем шаблон без дополнительных квалификаторов и &(as is), то при выведении типа переменной будут проигнорированы ссылочность и квалификаторы const, volatile. Это означает, что произойдёт сохранение по значению(cppinsights в данном случае показывает все типы, с которыми был инстанцирован шаблон):

template<typename T> 
void foo(T param)
{}

void main()
{
  // Вывод: Xray ctor, value is 1
  foo(Xray{"1"}); // type = Xray
} // Вывод: Xray dtor, value is 1
Примеры отбрасывания квалификаторов при выведении через шаблон

Смотрите вывод типов на cppinsights:

template<typename T> 
void foo(T param)
{}

int i = 0;
int& iRef = i;
const int& iConstRef = i;
volatile int& iVolatileRef = i;
const volatile int& iCVRef = i;
int* iPtr = &i;

foo(i);            // type = int
foo(iRef);         // type = int
foo(iConstRef);    // type = int
foo(iVolatileRef); // type = int
foo(iCVRef);       // type = int
foo(iPtr);         // type = int*

Чтобы добавить квалификаторы или ссылочность(или сохранить их при выводе типа) нужно указать их рядом с именем параметра шаблона.

В данном случае при этом произойдет продление жизни через константную lvalue ссылку(cppinsights):

template<typename T> 
void foo(const T& param)
{}

void main()
{
  // Вывод: Xray ctor, value is 1
  foo(Xray{"1"}); // type = const Xray&
} // Вывод: Xray dtor, value is 1

Также есть возможность указать T&&(идеальную ссылку), механизм вывода типа и передачи значения через которую называется perfect forwarding.

В данном случае произойдет продление жизни через rvalue ссылку(cppinsights):

template<typename T> 
void foo(T&& param)
{}

void main()
{
  // Вывод: Xray ctor, value is 1
  foo(Xray{"1"}); // type = Xray&&
} // Вывод: Xray dtor, value is 1
Примеры вывода типа через T&&

Смотрите вывод типов на cppinsights:

template<typename T> 
void foo(T&& param)
{}

int i = 0;
const int& iConstRef = i;

foo(i);            // type = int&
foo(4);            // type = int&&
foo(std::move(i)); // type = int&&
foo(iConstRef);    // type = const int&

Более подробное рассмотрение шаблонов и их отличий от других способов выведения типов выходит из рамок данной статьи, но вы можете ознакомиться с некоторыми статьями:

  1. @semenyakinVSПросто о шаблонах

  2. @4eyes О шаблонах С++, чуть сложнее


3. Рекомендации и подводные камни

3.1 Прежде чем объявить ссылку на другую ссылку убедитесь, что последняя не указывает на временный объект

Возврат ссылки из функции не продлевает время жизни, с чем связана одна из самых распространенных проблем у начинающих - они возвращают ссылку на временное значение из функции. Смотрите вывод типов на cppinsights:

const Xray& foo() 
{ 
  return Xray(“1”); 
}

// Все примеры ниже - неверные. Время жизни не будет продлено.
const Xray& _1= foo(); // Висячая ссылка
	
auto _2 = foo(); // Тип Xray. Значение с неопределённым содержимым в Xray::mValue.
const auto& _3 = foo(); // Тип const Xray&, висячая ссылка
auto&& _4 = foo();      // Тип const Xray&, висячая ссылка
  
decltype(auto) _5 = foo();  // Тип const Xray&, висячая ссылка
decltype(foo()) _6 = foo(); // Тип const Xray&, висячая ссылка

В данном случае временный объект разрушится перед выходом из функции, поэтому возвращаемая ссылка будет висячей. В связи с этим компилятор даже выдаст предупреждение(запуск программы на godbolt):

warning: returning reference to local temporary object

Но оно не поможет вам, если вы не читаете предупреждения, либо же если при сборке у вас их больше сотни(можно проглядеть). Поможет только знание этого нюанса и внимательность, или санитайзер.

3.2 Не используйте std::move там где может использоваться NRVO

Что такое NRVO?

NRVO (оптимизация именованного возвращаемого значения) - одна из форм copy elision, которая позволяет не копировать и не перемещать именованное значение при возврате его из функции.

В данном примере str - именованное значение(у него есть имя "str"), и если компилятор умеет делать NRVO, то не будет ни копирования ни перемещения, объект прямо поместится в value:

std::string foo() 
{
    std::string str;
    // .. изменение str
    return str; 
}

std::string value = foo();

Так же существует оптимизация RVO(оптимизация возвращаемого значения), это более простая форма той же оптимизации, когда мы не даём возвращаемому значению имя.

В данном примере std::string{"1"} - неименованное значение(у него нет имени, по сравнению с str из предыдущего примера), и если компилятор умеет делать RVO, то не будет ни копирования ни перемещения, объект прямо поместится в value:

std::string foo() 
{
    return std::string{"1"}; 
}

std::string value = foo();

Если хотите узнать больше про NRVO и RVO, то можете изучить статью @BykoIanko RVO и NRVO в C++17.

В целях оптимизации производительности иногда может возникать желание написать так:

std::string&& foo() 
{
    std::string str;
    // .. изменение str
    return std::move(str); 
}

В данном примере проблема в том, что возвращенная ссылка будет висячей, поскольку она будет указывать на локальный объект, который разрушится при выходе из функции. В связи с этим компилятор даже выдаст предупреждение, но вы можете его не заметить среди сотен других(запуск программы на godbolt):

warning: returning address of local variable or temporary: str

Если вы сильно переживаете за то что не сработает NRVO(но вероятнее всего оно сработает, почти все современные компиляторы уже умеют его делать), то лучше возвращать по значению:

std::string foo() 
{
    std::string str;
    // .. изменение str
    return std::move(str);
}

А ещё лучше - положиться на NRVO и не делать move.

3.3 Прежде чем продлевать время жизни убедитесь, что значение не является xvalue (Xray&&)

В C++03 время жизни временных объектов продлевалось при сохранении его по константной ссылке. Начиная с C++11 появились xvalue у которых время жизни объекта продлить нельзя. Разбор всех категорий значений выходит за рамки этой статьи, но чтобы говорить более предметно, я уточню: существуют несколько категорий значений вроде prvalue(то что мы до этого рассматривали как rvalue), lvalue, xvalue.

В данном случае нас интересуют xvalue. В перегрузках функций, xvalue ведут себя как rvalue, то есть xvalue будет передано в функцию как правосторонняя ссылка T&&(если такая перегрузка есть).
Пример: если у класса есть перемещающий конструктор, то будет вызван он, а не конструктор копирования(который бы был вызван в случае передачи lvalue):

Xray& lvalue();
Xray prvalue();
Xray&& xvalue();

Xray _1 = lvalue();  // Копирование Xray(Xray)
Xray _2 = prvalue(); // copy elision
Xray _3 = xvalue();  // Перемещение Xray(Xray&&)

Время жизни xvalue нельзя продлить (как и lvalue). Попытка сделать это приведёт к висячим ссылкам:

Xray const& _1 = prvalue(); // время жизни как у ссылки
Xray&& _2 = prvalue();      // время жизни как у ссылки
    
Xray& _3 = lvalue();       // висячая ссылка, не продлевает время жизни
const Xray& _4 = lvalue(); // висячая ссылка, не продлевает время жизни
Xray&& _5 = xvalue();      // висячая ссылка, не продлевает время жизни
const Xray& _6 = xvalue(); // висячая ссылка, не продлевает время жизни

3.4 При создании RAII объекта всегда сохраняйте его значение в переменную, либо же объявляйте ссылку на него

Нужно быть внимательным ко времени жизни объекта, если он является RAII оберткой. Например, не стоит объявлять std::lock_guard временным не сохранив ссылку на него(или не сохранив по значению), потому что это может привести к преждевременному освобождению мьютекса, а значит появятся гонки:

void main()
{
  std::lock_guard<std::mutex> lock{someMutex};
  /* Так нельзя:
     std::lock_guard<std::mutex>{mutex};
     Потому что компилятор 
     может разрушить lock_guard ещё до выхода из main,
     что приведёт к гонкам(собственно к тому, от чего мы и защищаемся мьютексом)
  */ 

  // .. многопоточно безопасные вызовы
  // .. изменение защищенных мьютексом значений
}

Если вы подумали о том, что создание такого временного объекта может быть упразднено оптимизатором, то это не так, потому что в данном случае конструктор с деструктором имеют сайд эффекты. В некоторых случаях оптимизатор может заинлайнить код конструктора и деструктора, но при этом функциональность программы останется неизменной.

3.5 Прежде чем объявить ссылку на другую ссылку убедитесь, что последняя не указывает на временный объект

Продлевать жизнь временного объекта можно лишь один раз - при первой привязке к ссылке. Схема вроде &-указывает на>&-указывает на>временный объект не продлевает время жизни повторно, а приводит к висячей ссылке и неопределённому поведению при её использовании:

template<class T> 
const T& foo(const T& in) 
{ 
  return in; 
}

const Xray& ref1 = X(1); // Верно, время жизни будет продлено.

Xray& ref2 = foo(X(2)); // Неверно, время жизни не будет продлено, 
                        // ref2- висячая ссылка.
std::cout << ref2.mValue; // Неопределённое поведение

3.6 Не продлевайте жизнь через тернарный оператор(?:)

При сохранении ссылки на выражение, полученное через тернарный оператор, будет продлено время жизни одного из временных значений, в зависимости от условия:

Xray&& rvalRef = cond 
                ? Xray{“1”}  // Один из временных объектов
                : Xray{“2”}; // будет иметь время жизни rvalRef

const Xray& constLvalRef = cond 
                ? Xray{“1”}  // Один из временных объектов
                : Xray{“2”}; // будет иметь время жизни constLvalRef

Данный механизм не интуитивен, поэтому я не рекомендую использовать его в вашем коде.

3.7 Не используйте ссылки в полях классов(особенно если они указывают на временные объекты) и не используйте std::reference_wrapper для продления жизни

Во-первых, создание ссылок в полях класса на объекты, временем жизни которых класс не управляет, с большей вероятностью(по сравнению с передачей по значению) может привести к висячим ссылкам.

Во-вторых, сам этот механизм работает нестабильно. Хоть в стандарте и сказано: если временный объект имеет ссылочное поле, инициализированное другим временным объектом, то продление времени жизни рекурсивно применяется к инициализатору этого поля:

struct X 
{ 
  const int& lvalRef; 
};

const X& lvalRef = X{1}; // Временные значения X и (int)1 будут иметь время жизни lvalRef 
X&& rvalRef = X{1};      // Временные значения X и (int)1 будут иметь время жизни rvalRef 

auto&& _1 =  X{1};         // Тоже ок, тип Xray&&(продление по rvalue ссылке)
decltype(auto) _2 =  X{1}; // Тоже ок, тип Xray(сохранение по значению)

Но похоже, что этот трюк срабатывает только если у вас aggregate-initialization(в случае вызова Xray x{1}) или если компилятор поддерживает copy elision(в случае вызова Xray x = Xray{1}). Возвращаясь к нашему примеру, добавив конструктор для инициализации нашего значения, он начинает вести себя нестабильно на разных компиляторах:

struct X 
{ 
	template<typename T>
  X(T&& l)
		: val(l)
  {}
  
	const int& val;
};

const X& lvalRef = X{1}; // Висячая ссылка, значение lvalRef.val == 0
X&& rvalRef = X{1};      // Висячая ссылка, значение rvalRef .val == 0
auto&& _1 =  X{1};       // Висячая ссылка, значение _1 .val == 0, тип X&&(продление по rvalue ссылке)
decltype(auto) _2 =  X{1}; // Тип X(сохранение по значению),
                           // На msvc(trunk) значение _2 .val == 1, 
                           // но на gcc(trunk) это висячая ссылка, значение _2 .val == 0

Наиболее интересной выглядит часть decltype(auto) _2 = X{1}, которая компилируется в X _2 = X{1} и её результаты. Исходная формулировка, которая описывает выражения у которых расширяется время жизни несколько туманна, и по ней не до конца понятен весь список ситуаций, которые имеются ввиду:

the initializer expression is used to initialize the destination object

Но я предполагаю, что в случае decltype(auto) _2 =  Xray{1} время жизни должно быть продлено, потому что временный объект используется в выражении, которое является инициализатором поля Xray. Поэтому думаю, что то, что время жизни не продлевается - баг компилятора.

В связи с вышеописанным я не рекомендую использовать ссылки на временные значения в полях класса, поскольку этот механизм:

  1. Работает нестабильно в зависимости от компилятора.

  2. Имеет туманную формулировку, на основе которой приходится строить догадки.

3.8 При передаче в new временных значений, убедитесь, что ни одно из них не сохраняется по ссылке

Временные объекты, переданные как параметры при инициализации в new, будут жить до тех пор пока не закончится вызов new. Это означает, что не стоит сохранять ссылки на временные значения в полях класса, который создается через new, поскольку это приведет к висячим ссылкам:

struct S 
{ 
  int i; const std::pair<int,int>& pair; 
};

S a { 1, {2,3} };         // верно, хоть и работает нестабильно(см. п.3.7)
S* p = new S{ 1, {2,3} }; // неверно, p->pair - висячая ссылка

3.9 Не продлевайте время жизни временного массива через ссылку на его элементы

В С++ есть возможность продлить время жизни временного массива, создав ссылку на один из его элементов. Я рекомендую использовать этот механизм только в полемике на кухне с коллегами(и, возможно, в метапрограммировании на старых стандартах С++), поскольку он интуитивно не понятен.

Но тем не менее подобный код, как бы не казалось, не создает висячих ссылок, время жизни временного массива будет продлено до времени жизни ссылки на его элемент:

int id = 0;
int&& a = int[2]{1, 2}[id];

Заключение

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

Сжальтесь над программистом, который будет читать то что вы написали, он может не знать всех этих нюансов. Да даже если он где-то про них и слышал и даже знает некоторые из них, то ему может не хватить концентрации чтобы уследить за каждым. Вероятнее всего даже самый образованный специалист, читающий ваш код, через раз всё равно будет сомневаться не висячая ли это ссылка.

Большинство данных механизмов и связанных с ними подводных камней стоит использовать только в теоретических изысканиях и операциях по обезвреживанию опасного кода. Избегайте остроумия и HolyHandGrenade, всем KISS.

Продление жизни временных значений в С++: рецепты и подводные камни - 4

Автор: Евгений

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js