Разберите, почему std::string_view может стать висячим представлением после возврата из функции.
std::string_view не владеет символами, а хранит только указатель на их начало и длину. Если функция возвращает представление данных локального или временного объекта, этот объект уничтожается, и возвращённый string_view становится висячим.
Передача string_view безопасна только пока гарантированно живёт исходный буфер и не нарушены условия его использования. Для хранения данных после завершения владельца нужно копировать их в std::string или другой владеющий контейнер.
До появления std::string_view функции часто принимали пару «указатель на символы плюс длина» либо const std::string&. Первый вариант неудобен и легко приводит к ошибкам, второй может требовать наличия объекта std::string и хуже выражает намерение использовать только временное представление текста.
std::string_view стандартизирован в C++17 как лёгкий невладеющий тип для работы с непрерывным диапазоном символов. Он позволяет без копирования передавать строки, литералы и части строк, но не меняет правил времени жизни исходных данных.
При возврате std::string_view вызывающая сторона получает адрес и размер диапазона, но не получает объект-владелец. Если исходная строка была локальной переменной, временным объектом или частью объекта, который уже уничтожен, чтение через представление обращается к недействительной памяти.
Особенно опасны такие ошибки, потому что программа может некоторое время показывать правильный результат: память ещё не перезаписана, а неопределённое поведение проявляется только после изменения оптимизации, компилятора или нагрузки.
std::string_view обычно концептуально состоит из указателя на первый символ и количества символов. Конструктор или возврат string_view не копирует символы и не продлевает время жизни объекта, на который они указывают.
В примере временный std::string уничтожается в конце полного выражения внутри bad_name. Возврат string_view копирует только адрес и длину, поэтому после уничтожения строки представление недействительно. Правило продления времени жизни временного объекта для ссылки здесь не помогает: string_view не является ссылкой на объект-владелец.
Безопасные источники обычно имеют время жизни, превышающее время использования представления: строковый литерал, живущий всю программу, объект std::string вызывающего кода или буфер, управляемый внешним владельцем. Однако даже у живого std::string представление может стать недействительным после операции, вызвавшей перераспределение буфера, например после некоторых изменений размера.
Для API полезно разделять два сценария:
std::string_view, использует его только во время вызова и не сохраняет;std::string.std::string_view также не обязан быть нуль-терминированным. Вызов data() возвращает указатель на начало диапазона, но за последним символом не обязательно находится \0, поэтому такой указатель нельзя без дополнительных гарантий передавать функциям, ожидающим C-строку.
Сервис разбирает HTTP-заголовки и сначала принимает их как std::string_view, чтобы не копировать входной буфер. Разбор выполняется немедленно, поэтому такой интерфейс эффективен: функция читает диапазон и возвращает структурированные значения.
Затем появилась очередь отложенной обработки. Первый вариант сохранял string_view на каждый заголовок. Он был быстрым и экономил память на копиях, но оказался ошибочным: исходный сетевой буфер переиспользовался после завершения чтения, поэтому элементы очереди ссылались на изменённые или уже недействительные данные.
Вариант с безусловным копированием на границе каждого API был безопаснее, но добавлял копирование даже для синхронных операций. Выбранное решение разделило интерфейсы: синхронный парсер принимает std::string_view, а очередь при постановке задачи копирует нужные поля в собственные std::string.
Так удалось сохранить отсутствие лишних копий в горячем синхронном пути и получить явное владение данными там, где требуется отложенное использование.
Продлевает ли const std::string& время жизни временной строки, если из неё создать std::string_view?
Если временная строка непосредственно привязана к локальной const std::string&, её время жизни действительно может продлиться до конца области действия этой ссылки. Но созданный string_view не продлевает жизнь строки самостоятельно. После выхода из области действия ссылки строка уничтожается, и сохранённое представление становится недействительным. Тем более нельзя возвращать такой view из функции, если владелец был локальной ссылкой.
Остаётся ли std::string_view действительным после изменения исходного std::string без перераспределения?
Если операция перераспределила буфер, прежний указатель недействителен. Если перераспределения не было, адрес обычно сохраняется, но содержимое диапазона может измениться, а правила конкретной операции могут ограничивать действительность указателей и итераторов. Поэтому view нельзя рассматривать как снимок строки: для независимого значения нужна копия, а при длительном хранении следует не полагаться на стабильность внутреннего буфера изменяемой строки.
Можно ли передать любой std::string_view в функцию, ожидающую нуль-терминированную строку?
Нет. string_view описывает диапазон с явной длиной, и за его концом может не быть нулевого символа. Это относится, например, к результату substr или к части более длинной строки. Передача data() в C-API безопасна только при отдельной гарантии нуль-терминации; иначе нужно создать std::string или использовать API, принимающий указатель вместе с длиной.