Краткий ответ

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

Исторический контекст

Ссылки в C++ предназначены для обращения к объектам без копирования и без передачи владения. Это удобно для параметров функций и конструкторов, но требует явно соблюдать время жизни объекта, на который они ссылаются.

Подход RAII и умные указатели появились как способы сделать владение ресурсами явным и автоматически управляемым. Ссылка при этом остаётся невладеющим средством доступа: сама по себе она не заменяет владельца и не обеспечивает продление жизни объекта.

Постановка проблемы

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

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

Подробное решение

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

#include <iostream>
#include <string>

class View {
    const std::string& text;
public:
    explicit View(const std::string& value) : text(value) {}
    void print() const { std::cout << text << '
'; }
};

int main() {
    View view{std::string("temporary")};
    view.print(); // неопределённое поведение: строка уже уничтожена
}

В данном примере временная строка уничтожается после завершения полного выражения View view{...};. Поле text не становится владельцем строки и не получает более длительное время жизни.

Надёжные варианты зависят от семантики класса:

хранить значение std::string, если класс должен владеть независимой копией;
хранить std::string_view, если класс является невладеющим представлением и его API явно требует, чтобы внешний объект жил достаточно долго;
хранить std::shared_ptr<const std::string>, если владение действительно разделяется;
принимать только lvalue или использовать другой контракт, если временные объекты недопустимы.

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

Ситуация из практики

Компонент форматирования принимал const std::string& и сохранял её в поле, чтобы не копировать большие шаблоны. В тестах использовались именованные строки, поэтому ошибка не проявлялась. В рабочем коде компонент часто создавался из результата преобразования строки, после чего обращение к шаблону читало уже уничтоженную память.

Рассматривались три решения. std::string_view устранял копирование, но сохранял требование к времени жизни и не исправлял контракт. std::shared_ptr гарантировал жизнь данных, но добавлял совместное владение и накладные расходы. Хранение std::string увеличивало число копирований, зато сделало объект самодостаточным и упростило API.

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

Что кандидаты часто упускают

Продлевает ли const-ссылка, сохранённая в поле, жизнь временного объекта?

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

Безопасен ли такой класс, если конструктору передали именованную строку?

Только пока именованная строка продолжает жить и не уничтожена раньше объекта-контейнера. Кроме того, операции над самой строкой, например перемещение или некоторые изменения, могут изменить содержимое или сделать ранее сохранённое представление непригодным для ожидаемого использования. Безопасность обеспечивается не фактом именованности, а гарантированным временем жизни и подходящими правилами доступа.

Что выбрать: копирование строки или std::string_view?

Копирование следует выбрать, когда объект должен владеть данными или переживать источник. std::string_view подходит для краткоживущего невладеющего доступа, если API явно документирует требование к времени жизни и не сохраняет представление дольше допустимого срока. string_view не выполняет копирование и не продлевает жизнь строки, поэтому он не является исправлением для неизвестного или нестабильного времени жизни.