Error returning reference to temporary

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

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

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

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

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

Оглавление

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

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

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

• 1.2 rvalue ссылка

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

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

• 2.1 auto

• 2.2 decltype

• 2.3 decltype(auto)

• 2.4 template

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

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

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

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

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

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

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

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

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

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

• Заключение

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

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

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

2. Всё.

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

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

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

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

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

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

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

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

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

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

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

Класс 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. Способы продления времени жизни и сохранения временных значений

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

Если мы так сделаем, то компилятор вызовет деструктор в той же строке. Пример на godbolt:

void main()
{
  // Вывод: Xray ctor, value is 1
  // Вывод: Xray dtor, value is 1
  Xray{"1"};
  
  std::cout << "Wait a sec" << std::endl;
}

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

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

int i = 3;
int& iRef = i;

Теперь же рассмотрим вариант с созданием константной 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

Почему компиляция этого примера не завершается ошибкой?

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

1.2 rvalue ссылка

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

int&& iRvalueRef = 3;

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

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

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

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)

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

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&&

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(2+2) не будет вычисляться результат сложения 2+2, компилятор будет рассматривать это выражение только с точки зрения типов: (int)+(int), результат — int.

При этом вы вероятно заметили, что использовать 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

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

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

Примеры отбрасывания квалификаторов при выведении через шаблон

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*

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

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&&

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?

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

std::string value = foo();

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

std::string value = foo();

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

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 = Xray(1); // Верно, время жизни будет продлено.

Xray& ref2 = foo(Xray(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(в случае вызова X x{1}) или если компилятор поддерживает copy elision (в случае вызова X x = X{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 =  X{1} время жизни должно быть продлено, потому что временный объект используется в выражении, которое является инициализатором поля X. Поэтому думаю, что то, что время жизни не продлевается — баг компилятора.

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

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];

К нашему счастью, код в таком виде не скомпилируется. Чтобы он заработал нужно будет создавать массив чуть менее очевидным способом (cppinsights):

template<typename T>
using dummy = T;

int main()
{
  int i = 1;
  const int& a = dummy<int[2]>{1, 2}[i]; // тип const int&
}

При этом можно так же продлить жизнь через rvalue ссылку:

int&& a = dummy<int[3]>{1, 2, 3}[i];

Хотя пример с rvalue ссылкой уже ведёт себя нестабильно на разных компиляторах:

• На gcc всё работает как надо (godbolt).

• А на msvc ошибка компиляции cannot convert from 'int' to 'int &&' (godbolt).

Судя по всему, это баг msvc. Но мы можем обойти его если будем принимать значение через auto&& (godbolt, cppinsights):

auto&& a = dummy<int[3]>{1, 2, 3}[i]; // тип int&&

Заключение

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

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

UPD 06.06:

1. Исправил ошибку в разогревающем примере из 1. Способы продления времени жизни и сохранения временных значений. Спасибо @HungryD!

2. Добавил поясняющий комментарий в примере с lock_guard из 3.4 При создании RAII объекта всегда сохраняйте его значение в переменную, либо же объявляйте ссылку на него. Спасибо @findoff!

UPD 07.06:

1. Исправил ошибку в примере и добавил более подробный анализ в 3.9 Не продлевайте время жизни временного массива через ссылку на его элементы. Спасибо @Apoheliy!

Была ли вам полезна статья?

Проголосовали 74 пользователя.

Воздержались 18 пользователей.

• They’re in the trees, Johnny!
• 1. Ways to extend the lifetime and to store temporary objects
  • 1.1 Const lvalue reference
  • 1.2 rvalue reference
  • 1.3 Storing by value
• 2. Type deduction
  • 2.1 auto
  • 2.2 decltype
  • 2.3 decltype(auto)
  • 2.4 template
• 3. Tips and tricks
  • 3.1 Before referencing another reference, make sure that this ‘another’ reference doesn’t point out at a temporary object
  • 3.2 Do not use std::move when NRVO can be used
  • 3.3 Make sure that the value is not xvalue (Xray&&) before extending the lifetime of temporary objects
  • 3.4 Always save the value of the RAII object created into the variable, or declare a reference to it
  • 3.5 Before referencing another reference, make sure that this ‘another’ reference doesn’t point out at a temporary object
  • 3.6 Do not extend the lifetime of a temporary object via the ternary operator ?:
  • 3.7 Do not use references in class fields (if they point to temporary objects especially) and do not use std::reference_wrapper to extend the lifetime of a temporary object
  • 3.8 When passing temporary objects to new, make sure that none of them are stored by reference
  • 3.9 Do not extend the lifetime of a temporary array through a reference to its elements
• Conclusion

After reading this article, you will learn the following: ways to extend the lifetime of a temporary object in C++, various tips and tricks; pitfalls of the lifetime extension that a C++ programmer may face, and that I have already faced myself.

This article may be useful not only for beginners but also for advanced developers.

If interested, grab a cup of tea and let’s go find out where the references are dangling.

We published and translated this article with the copyright holder’s permission. The author is Evgeny Neruchek (cheshirwr@mail.ru). The article was originally published on Habr.

They’re in the trees, Johnny!

To begin with, let’s identify a range of possible problems with references:

• Dangling references.
• That’s all.

You may enumerate much more problems with the references, but any other issues pale in comparison with dangling references. Dangling references are the most frequent of any production problems.

For those who do not know, a dangling reference is a reference to memory that contains an object which no longer exists. It happens, when the lifetime of an object expires before the lifetime of the reference that points to it expires. The reference becomes dangling when the compiler destroys the object (calls a destructor for the object and then releases the storage space allocated for this object), while the reference to this object still exists.

And if someone uses this dangling reference anything can happen. The C++ standard describes this ‘anything’ as undefined behavior or UB.

Although we still can theorize what will actually happen in case of UB, but let me draw an analogy — what’s better: to investigate a murder or to prevent it? Since any program containing undefined behavior is a potential problem for a customer, it’s also our pain in the neck. That’s why I think avoiding and preventing undefined behavior is vital.

One of the reasons for dangling references is the peculiarities of the temporary objects’ lifetime extension. You can extend the lifetime of a temporary object since C++03 (the extension is made through the const lvalue references). In C++11 the extension mechanism was modified (rvalue references were added):

If you receive a temporary object by const lvalue reference or rvalue reference, then its lifetime is extended to the lifetime of the reference.

So, the lifetime extension is only available for referenced temporary objects. And yet, if we add storing by value to the proposition above, we get the following results:

• A const lvalue reference to the value of a temporary object.
• An rvalue reference to the value of a temporary object.
• Storing by value.

Although, from the C++ viewpoint, storing by value is not a specific mechanism for the lifetime extension, since the value of a temporary object must be copied or moved (the lifetime of the original temporary value is not extended). But let us go ahead:

• Copy elision optimization leads to the externally similar effects, as when storing by reference.
• Storing by value also has some details related to the lifetime extension through references.

We will take a closer look at each of these two options. But first let’s inspect the Xray class. The Xray class enables us to track the order of constructors’ and destructors’ calls.

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. Ways to extend the lifetime and to store temporary objects

To warm up, let’s start with the simplest option: when we don’t store the value of a temporary object but only create it.

In this case, the compiler calls the destructor in the same line. Here’s the example on godbolt:

void main()
{
  // Output: Xray ctor, value is 1
  // Output: Xray dtor, value is 1
  Xray{"1"};
  
  std::cout << "Wait a sec" << std::endl;
}

1.1 Const lvalue reference

int i = 3;
int& iRef = i;

Now let’s take a look at the second option of creating a constant lvalue reference to a temporary object:

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

Everything is simple: we create a value of a temporary object through Xray{«1»}  and then store the const reference to this object in xrayRef. After that, a value of a temporary object gets destroyed when the main function is exited (after the program’s execution flow encounters the end of the function body — the brace } ).

The following case is similar, but here the implicit type conversion from std::string to Xray occurs when creating a temporary object:

void main()
{
  // Output: Xray ctor, value is 1
  const Xray& xrayRef = std::string("1"); 
} // Output: Xray dtor, value is 1

The main advantage of this approach is that there are no extra copy constructor calls. But this approach is not the only one that has this advantage.

1.2 rvalue reference

int&& iRvalueRef = 3;

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

Xray xray = Xray{′123″};
Xray&& xrayRef = std::move(xray);

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

The rvalue reference is also used to point out at the value of a temporary object without any additional copy or move constructors being called.

void main()
{
  // Output: Xray ctor, value is 1
  Xray&& xrayRef = Xray{"1"};
} // Output: Xray dtor, value is 1

1.3 Storing by value

Storing by value looks as follows:

void main()
{
  // Output: Xray ctor, value is 1
  Xray xray = Xray{"1"}; 
} // Output: Xray dtor, value is 1

«Won’t the copy constructor be called?» — you may wonder looking at the case above.

But the copy elision optimization prevents redundant copying, so the copy/move constructor is not called. And moreover, even in this case only 1 constructor (which creates the Xray object) is called:

void main()
{
  // Output: Xray ctor, value is 1
  Xray xray = Xray{Xray{Xray{"1"}}}; 
} // Output: Xray dtor, value is 1

Since C++98, the copy elision optimization was introduced, but not all compliers supported it. Since C++17, all compilers are required to support the copy elision optimization.

2. Type deduction

In C++ type deduction refers to the automatic or half-automatic detection of the type of a variable. In this case, the compiler is able to deduce the type through the initializer (of the assigned expression).

The type-deduction mechanism determines only the way in which the type is deduced — as a reference or as a non-reference type. So, we still end up with one of the options from the first paragraph as a result of the type deduction: either passing by reference, or passing by value. We’re going to briefly discuss the ways of the type deduction to get the full picture.

I used cppinsights to check what type the complier deduced.

2.1 auto

Since C++11, we’re able to use the auto keyword to deduce the type of a variable through its initializer. If we use the auto keyword without any additional qualifiers and & (as is) during the type deduction of the variable type, then a reference declaration and the const and volatile type qualifiers are ignored. In this case storing by value occurs. Check the type deduction on cppinsights:

void main()
{
  // Output: Xray ctor, value is 1
  auto xray = Xray{"1"}; // type = Xray
} // Output: Xray dtor, value is 1

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*

To add qualifiers and a reference declaration (or to save them during the type deduction), you need to specify them next to the auto keyword. When qualifiers and reference types are added, the lifetime is extended through a const lvalue reference (cppinsights):

void main()
{
  // Output: Xray ctor, value is 1
  const auto& xray = Xray{"1"}; // type = const Xray&
} // Output: Xray dtor, value is 1

You can also specify auto&& so the type deduction mechanism would be quite similar to perfect forwarding. When you use auto&&, the lifetime is extended through an rvalue reference (cppinsights):

void main()
{
  // Output: Xray ctor, value is 1
  auto&& xray = Xray{"1"}; // type = Xray&&
} // Output: Xray dtor, value is 1

Learn more about perfect forwarding in the 2.4 template paragraph.

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

Since C++11 with the introduction of the decltype keyword, we’re able to obtain the type of an expression at compile time. The examples of the type deduction with the decltype keyword on 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

So, if you use the decltype keyword, then storing by value occurs:

void main()
{
  // Output: Xray ctor, value is 1
  decltype(Xray{"1"}) xray = Xray{"1"}; // type = Xray
} // Output: Xray dtor, value is 1

If you need to deduce the type of an object that does not have the required constructor (in particular, the default constructor), then you can use std::declval:

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

The type deduction at compile time means that an expression passed to decltype is processed not during program execution, but during compilation. The compiler only checks which type is the result of the expression and then substitutes it.

Example: in the decltype(2+2) expression, the result of the addition (2+2) is not processed, since the compiler sees this expression only in terms of types: (int)+(int), so the result is int.

You may have noticed that using decltype in this way is not very convenient:

1. You get a lot of extra information that completely or partially duplicates the expression being assigned.

2. Once in a while you have to use various workarounds (such as std::declval) to deduce the type.

That’s why decltype was modified into decltype(auto) in the next standard.

2.3 decltype(auto)

Since C++14, we’re able to pass the auto keyword to decltype as a parameter. With decltype(auto) we can deduce the same type as the one of the expressions assigned, thus the qualifiers and a reference declaration are saved.

The examples of the type deduction with decltype(auto) on 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&&

Thus, if you use decltype(auto), then storing by value occurs (cppinsights):

void main()
{
  // Output: Xray ctor, value is 1
  decltype(auto) xray = Xray{"1"}; // type = Xray
} // Output: Xray dtor, value is 1

2.4 template

The template type deduction is pretty similar to the auto type deduction.

If we specify the template type T (from template<typename T>) without any additional qualifiers and & (as is), during the template argument deduction in a function template, then a reference declaration and the const and volatile qualifiers are ignored. In this case storing by value occurs (on cppinsights you can see all the types instantiated with a template):

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

void main()
{
  // Output: Xray ctor, value is 1
  foo(Xray{"1"}); // type = Xray
} // Output: Xray dtor, value is 1

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*

To add qualifiers and a reference declaration (or to save them during the type deduction), you need to specify them next to the name of a template parameter.

In this case, the lifetime is extended via a const lvalue reference (cppinsights):

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

void main()
{
  // Output: Xray ctor, value is 1
  foo(Xray{"1"}); // type = const Xray&
} // Output: Xray dtor, value is 1

You can also specify T&& (forwarding reference) so the type deduction and the value passing mechanisms would be quite similar to perfect forwarding.

In this case, the lifetime is extended via an rvalue reference (cppinsights):

template<typename T> 
void foo(T&& param)
{}
void main()
{
  // Output: Xray ctor, value is 1
  foo(Xray{"1"}); // type = Xray&&
} // Output: Xray dtor, value is 1

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&

Learn more about various templates in other articles:

• Templates in simple words [RU] @semenyakinVS;
• A few more words about templates in C++ [RU] @4eyes.

3. Tips and tricks

3.1 Before referencing another reference, make sure that this ‘another’ reference doesn’t point out at a temporary object

When you return a reference from a function you don’t extend the reference’s lifetime. This is a typical problem for beginners — they return a reference to a temporary value from a function. Check the type deduction on cppinsights:

const Xray& foo() 
{ 
  return Xray(′′1′′); 
}

// All cases below are incorrect. Lifetime is not extended.
const Xray& _1 = foo(); // Dangling reference

auto _2 = foo(); // the Xray type. Undefined value
                 // content in Xray::mValue.
const auto& _3 = foo(); // the const Xray& type, dangling reference
auto&& _4 = foo();      // the const Xray& type, dangling reference
  
decltype(auto) _5 = foo();  // the const Xray& type, dangling reference
decltype(foo()) _6 = foo(); // the const Xray& type, dangling reference

In this case the temporary object gets destroyed when the function exits, so the returning reference is dangling. As a result, the compiler issues a warning (run a program on godbolt):

warning: returning reference to local temporary object

But this warning is useless if you have thousands of them (it’s easy to miss), or if you just don’t read warnings. You can only be aware of this nuance and be attentive, or to use a sanitizer tool.

3.2 Do not use std::move when NRVO can be used

std::string foo() 
{
    std::string str;
    // .. str change
    return str; 
}

std::string value = foo();

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

std::string value = foo();

To optimize performance, you may think of writing something like this:

std::string&& foo() 
{
    std::string str;
    // .. str change
    return std::move(str); 
}

In the above case, the returning reference is dangling because it points at the local object that gets destroyed when the function is exited. So, the compiler issues a warning which can easily be missed among other warnings (run a program on godbolt):

warning: returning address of local variable or temporary: str

You can return by value just in case you’re worried that NRVO would not be performed (but it would, since all modern compilers are able to perform it):

std::string foo() 
{
    std::string str;
    // .. str change
    return std::move(str);
}

But it’s always better to rely on NRVO and not use move.

3.3 Make sure that the value is not xvalue (Xray&&) before extending the lifetime of temporary objects

In C++03, the lifetime of temporary objects was extended through saving them by a constant reference. Since C++11, xvalues were introduced whose lifetime couldn’t be extended. We’re not going to analyze all value categories in detail. So, long story short, there are several value categories: prvalue (that was previously described as rvalue), lvalue and xvalue.

In this particular case we speak about xvalue. In overloads of the called functions, xvalues are quite similar to rvalues. Thus, xvalue is passed into the function as an rvalue reference T&& (if there’s an overload of the called function).

Example: the move constructor is called, if the class has one (the copy constructor is called when an lvalue reference is passed):

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

Xray _1 = lvalue();  // Xray(Xray) copying
Xray _2 = prvalue(); // copy elision
Xray _3 = xvalue();  // Xray(Xray&&) moving

You cannot extend the lifetime of xvalue (the same is true for lvalue). The lifetime extension of xvalue results in dangling references:

Xray const& _1 = prvalue(); // the lifetime of a reference
Xray&& _2 = prvalue();      // the lifetime of a reference
    
Xray& _3 = lvalue();       // dangling reference, does not extend the lifetime
const Xray& _4 = lvalue(); // dangling reference, does not extend the lifetime
Xray&& _5 = xvalue();      // dangling reference, does not extend the lifetime
const Xray& _6 = xvalue(); // dangling reference, does not extend the lifetime

3.4 Always save the value of the RAII object created into the variable, or declare a reference to it

It would be better to pay special attention to the lifetime of the RAII object. For example, don’t declare std::lock_guard as a temporary object, when you don’t save a reference to it (or don’t store the object by value). It leads to the early mutex release, which creates a race condition:

void main()
{
  // Do this
  std::lock_guard<std::mutex> lock{someMutex};
  
  /* Don't do that:
     std::lock_guard<std::mutex>{mutex};
     The complier destroys lock_guard before it leaves main,
 which creates race conditions (that we are trying to avoid with mutex)
  */ 

  // .. multi-threaded safe calls
  // .. changing mutex-protected values
}

You may have thought that the creation of a temporary object is canceled by the optimizer, but it is not. In this case, constructor and destructor have side effects. In some other cases, the optimizer may inline the constructor and destructor code, but the functionality of the program is the same.

3.5 Before referencing another reference, make sure that this ‘another’ reference doesn’t point out at a temporary object

You can extend the lifetime of a temporary object once, when binding to a reference for the first time. When you do ‘&-points to>&-points to>temporary object’, it does not extend the lifetime repeatedly, but it leads to a dangling reference and undefined behavior:

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

const Xray& ref1 = X(1); // True, the lifetime is extended.

Xray& ref2 = foo(X(2)); // False, the lifetime is not extended, 
                        // ref2 — dangling reference.
std::cout << ref2.mValue; // Undefined behavior

3.6 Do not extend the lifetime of a temporary object via the ternary operator ?:

If you save a reference to an expression obtained with a ternary operator, the lifetime of one of the temporary objects extends depending on the condition:

Xray&& rvalRef = cond 
                ? Xray{′′1′′}  // One of the temporary objects
                : Xray{"2"}; // will have a lifetime of rvalRef

const Xray& constLvalRef = cond 
                ? Xray{′′1′′}  // One of the temporary objects
                : Xray{"2"}; // will have a lifetime of constLvalRef

Since this mechanism is not so easy-to-use, I would not recommend you to use it in your code.

3.7 Do not use references in class fields (if they point to temporary objects especially) and do not use std::reference_wrapper to extend the lifetime of a temporary object

The first reason is that when you create references in class fields to objects whose lifetime is not controlled by the class, this is more likely to result in dangling references (compared to passing by value).

The second reason — this mechanism is unstable. Although the standard specifies that if a temporary object has a reference field initialized by another temporary object, then the lifetime extension is recursively applied to the initializer of this field:

struct X 
{ 
  const int& lvalRef; 
};

const X& lvalRef = X{1}; // Temporary objects X and (int)1
                         // will have a lifetime of lvalRef 
X&& rvalRef = X{1};      // Temporary objects X and (int)1
                         // will have a lifetime of rvalRef 

auto&& _1 = X{1};         // It's also ok, the type is Xray&&  
                          // (extension with an rvalue reference)
decltype(auto) _2 = X{1}; // It's also ok, the type is Xray 
                          // (storing by value)

But it seems like it works only if there is an aggregate-initialization (when Xray x{1}) is called), or if the compiler supports copy elision (when Xray x = Xray{1} is called). So, returning to our case, the constructor added to initialize the value is unstable on different compilers:

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

const X& lvalRef = X{1}; // Dangling reference, the lvalRef.val value == 0
X&& rvalRef = X{1};      // Dangling reference, the rvalRef .val value == 0
auto&& _1 = X{1};        // Dangling reference, the _1 .val value == 0,
                         // the X&& type (has a lifetime of rvalue)
decltype(auto) _2 = X{1};  // X type (storing by value),
                           // On msvc(trunk) the _2 .val value == 1,
                           // but on gcc(trunk) it's dangling,  
                           // the _2 .val value == 0

The decltype(auto) _2 = X{1} part, which is compiled into X _2 = X{1}, and its results seem to be the most curious. The following description of the expressions with the lifetime extended is pretty much obscure:

the initializer expression is used to initialize the destination object

But I think that in case of decltype(auto) _2 =  Xray{1}, the lifetime is extended, since the temporary object is used in the initializer expression of the Xray field. So, I think that this ‘non-extension’ of the lifetime is a compiler bug.

That’s why I wouldn’t recommend you to reference temporary objects in class fields, because:

• This mechanism depends on the compiler and may be unstable;
• You can only guess the result, since the description of the mechanism is unclear.

3.8 When passing temporary objects to new, make sure that none of them are stored by reference

Temporary objects were passed as parameters when initializing to new. Thus, the lifetime of these objects lasts until the new call is executed. It means that storing references to temporary objects in class fields (that are created through new) results in dangling references:

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

S a { 1, {2,3} };         // true, but it's unstable (see 3.7)
S* p = new S{ 1, {2,3} }; // false, p->pair — dangling reference

3.9 Do not extend the lifetime of a temporary array through a reference to its elements

You can extend the lifetime of a temporary array by referencing one of its elements. C++ has a special mechanism for this. But I would recommend you using it only in the disputes with your co-workers (and maybe in metaprogramming with the old C++ standards), since this mechanism is not so easy-to-use.

However, using this mechanism does not result in dangling references, and the lifetime of the temporary array is extended to the lifetime of the reference to its element:

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

Fortunately, the code in its current form is not compiled. You need to create an array in a less obvious way to make this code work (cppinsights):

template<typename T>
using dummy = T;

int main()
{
  int i = 1;
  const int& a = dummy<int[2]>{1, 2}[i]; // the const int& type
}

You can also extend the lifetime of a temporary object through an rvalue reference:

int&& a = dummy<int[3]>{1, 2, 3}[i];

However, the lifetime extension through an rvalue reference is sometimes unstable on different compilers:

But everything is ok on gcc (godbolt).

There is a compilation error on msvc: cannot convert from ‘int’ to ‘int &&’ (godbolt).

It’s likely to be a msvc’s bug. But we still can get around this bug, if we take the value via auto&& (godbolt, cppinsights):

auto&& a = dummy<int[3]>{1, 2, 3}[i]; // the int&& type

Conclusion

Saving the value by a constant reference is stressful for anyone who has ever faced a dangling reference. It’s important to monitor an object’s lifetime. It would be better not to put it on the compiler.

Please, have mercy on a developer who is going to read your code, they may not know all the shades of the object’s lifetime extension. And if they do know something about it, they may not be able to keep an eye on everything at once. Even the most educated computer science expert may doubt when reading your code whether a reference is dangling or not.

It would be better to use most of these mechanisms only in theoretical research or to neutralize dangerous code.

Stay away from any over-thinking stuff and HolyHandGrenade. KISS.

<source>: In function 'const A& foo()':
<source>:9:16: warning: returning reference to temporary [-Wreturn-local-addr]
    9 |         return A();
      |                ^~~

/app/example.cpp:9:18: runtime error: reference binding to null pointer of type 'const struct A'
/app/example.cpp:13:14: runtime error: member call on null pointer of type 'const struct A'

#include <vector>
#include <cstdio>
#include <cstdlib>
using namespace std;


void* operator new(std::size_t sz)
{
    std::printf("global op new called, size = %zun", sz);
    if (sz == 0)
        ++sz;
    if (void *ptr = std::malloc(sz))
        return ptr;
    throw std::bad_alloc{};
}

int main()
{
	// #1
	//global op new called, size = 80
	vector<int> v;
	v.reserve(20);
	v = {3, 4};
	
	// #2
	//global op new called, size = 80
	//global op new called, size = 8
	vector<int> v2;
	v2.reserve(20);
	v2 = vector<int>{3, 4};

	return 0;
}

	int a; 
	cin >> a;
	// #1
	//global op new called, size = 80
	vector<int> v;
	v.reserve(20);
	v = {a};

constexpr int f(int i) { return i; }

#include <iostream>
using namespace std;

int main()
{
	int a;
	cin >> a;
	return f(a); // и здесь тоже не может?
}

int main()
{
  vector<int> v = std::vector<int, std::allocator<int> >();
  v.reserve(20);
  v.operator=(std::initializer_list<int>{3, 4});
  vector<int> v2 = std::vector<int, std::allocator<int> >();
  v2.reserve(20);
  v2.operator=(std::vector<int, std::allocator<int> >{std::initializer_list<int>{3, 4}, std::allocator<int>()});
  return 0;
}

std::initializer_list<T> ilist

v.operator=(std::initializer_list<int>{3, 4});

v2.operator=(std::vector<int, std::allocator<int> >{std::initializer_list<int>{3, 4}, std::allocator<int>()});

vector& operator=( std::initializer_list<T> ilist );

//global op new called, size = 80
	//global op new called, size = 8

27 сентября 2021 г.