Правила безопасности времени жизни: owner и view

1. Зачем нужны правила и модель owner/view

Приятно думать, что компилятор — это строгий взрослый в комнате, который не даст вам сделать глупость. Но с временем жизни в C++ компилятор часто может лишь пожать плечами: «Типы-то совпадают… а вот жив ли объект — это уже ваша сюжетная линия». Из-за этого dangling-ошибки особенно неприятны: программа может работать, потом перестать, потом снова «почти работать», а вы будете подозревать погоду, фазу Луны и соседний Wi‑Fi.

Проблема в том, что ссылка, указатель, std::string_view и std::span — это не владение, а всего лишь «адрес + обещание, что там есть данные». Если обещание нарушили, язык не обязан вас спасать. Поэтому нам нужны человеческие правила — такие, чтобы вы могли посмотреть на API и сразу понять: «ага, кто владелец, а кто просто смотрит».

Owner и view: кто за что отвечает

Чтобы дальше не утонуть в терминах, договоримся о простой картинке. Владелец — это объект, который реально хранит данные и отвечает за их жизнь. View — это объект, который «смотрит» на чужие данные, но не управляет ими. Если владелец умер или переехал — view остаётся с адресом на память, которая уже не обязана содержать нужные байты.

Схема (очень упрощённая, но полезная):

flowchart LR
    Owner["Owner: std::string / std::vector / массив"] --> Buffer["Буфер в памяти"]
    View["View: string_view / span / T* / T&"] --> Buffer

Важная мысль: view не продлевает жизнь владельца. Он не «приклеивается» к объекту магией. Он как закладка в книге: если книгу сожгли, закладка не превращается в новую книгу.

2. Правило №1: owner живёт дольше view

Звучит банально, но именно это правило чаще всего спасает проект от «мистических» падений. Если у вас есть std::string_view sv, то где-то должен быть std::string s (или литерал, или другой долговечный источник), который гарантированно живёт, пока sv используется. И точно так же для std::span: должен быть массив/std::vector/std::array, чья память не исчезнет и не переедет.

Посмотрим на «хорошо» и «плохо» в максимально прикладном виде.

View как входной параметр — обычно безопасно

Когда функция принимает view и не сохраняет его, она использует «окно» только во время вызова. Это самый удачный контракт.

#include <iostream>
#include <string_view>

bool is_command(std::string_view s) {
    return !s.empty() && s[0] == '/';
}

int main() {
    std::cout << is_command("/add") << '\n';  // 1
    std::cout << is_command("hello") << '\n'; // 0
}

Здесь std::string_view живёт только внутри is_command. Мы не пытаемся вернуть его наружу и не кладём в поле структуры. Это прям «здоровая еда» для времени жизни.

View, построенный от временного владельца — классическая ловушка

Эта ошибка выглядит невинно: «ну это же одна строка, что может пойти не так?». А потом — UB.

#include <string_view>
#include <string>

int main() {
    std::string_view sv = std::string("hello"); // dangling после ';'
    (void)sv;
}

Почему? Потому что std::string("hello") — временный объект, он уничтожается в конце полного выражения (обычно в конце строки). А sv остаётся и указывает на память, которой больше никто не владеет.

Если очень хочется «создать строку и смотреть на неё», нужно сделать владельца именованным:

#include <string>
#include <string_view>

int main() {
    std::string s = "hello";
    std::string_view sv = s; // OK: s живёт дольше sv в этом scope
}

Возврат view наружу: безопасно только при строгом контракте

Возвращать std::string_view или std::span можно, но только если вы точно знаете, что источник переживёт возвращаемый view. Новичку легче запомнить более простое правило: если внутри функции создаёте данные — возвращайте владение (по значению).

Плохой пример (локальная строка умрёт при выходе):

#include <string>
#include <string_view>

std::string_view bad_title() {
    std::string s = "Do homework";
    return s; // dangling
}

Хороший вариант: вернуть std::string по значению.

#include <string>

std::string good_title() {
    std::string s = "Do homework";
    return s; // OK: возвращаем владение
}

Да, возвращаем «копию». Но в современном C++ это нормальная практика: возврат по значению оптимизируется (copy elision и оптимизации перемещений), а главное — контракт становится безопасным.

3. Правило №2: не храним view в полях без гарантий

Вот здесь обычно начинается настоящая боль. View-типы соблазнительны: «они маленькие, быстрые, без копий». И рука так и тянется сделать:

• в структуре Task хранить std::string_view title;
• в структуре «парсер» хранить std::span<const char> data;
• в модели хранить ссылку const std::string& name;

Проблема в том, что поле структуры живёт столько, сколько живёт структура. А вот данные, на которые смотрит view, могут жить меньше. И чаще всего так и происходит.

Антипример: модель хранит string_view, и всё ломается «потом»

Представим, что мы делаем простое консольное приложение TaskTracker: добавляем задачи, печатаем список. Наивное решение — хранить std::string_view в задаче.

#include <string_view>

struct TaskBad {
    std::string_view title; // НЕ владеем
};

Теперь смотрите, как легко туда случайно положить view на временное:

#include <iostream>
#include <string>
#include <string_view>

struct TaskBad {
    std::string_view title;
};

TaskBad make_bad() {
    return TaskBad{std::string("Read C++ book")}; // dangling после ';' внутри make_bad
}

int main() {
    TaskBad t = make_bad();
    std::cout << t.title << '\n'; // UB
}

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

Правильный подход: модель владеет данными

Если объект «по смыслу» хранит текст задачи — пусть он хранит std::string.

#include <string>

struct Task {
    std::string title; // владеем
};

А std::string_view используем там, где он действительно силён: на границе функций, как «прочитать вход».

4. Дизайн функций: value, const&, view

Сейчас будет важный момент: правила безопасности — это не «запретить всё интересное». Это про то, чтобы типом показать контракт, а не заставлять читателя догадываться.

Ниже — рабочая таблица (не единственно верная, но очень полезная для начинающих):

std::string_view

std::span<const T>

std::string

string_view / span

Самая частая ошибка новичка — возвращать ссылку/view «ради оптимизации», не понимая, что это ломает контракт времени жизни. В современном C++ безопаснее сначала сделать правильно, а потом оптимизировать там, где реально нужно (и где есть данные профилирования), а не «по ощущению».

5. TaskTracker: view на входе, владение внутри

Теперь соберём правила в небольшой пример. Мы будем читать команды построчно, парсить их, и хранить задачи в std::vector<Task>. Парсер будет активно использовать std::string_view, но задачи будут хранить std::string.

Модель задачи: владеем строкой

#include <string>

struct Task {
    std::string title;
    bool done = false;
};

Здесь всё скучно — а это комплимент. Скучный код с точки зрения времени жизни обычно означает «надёжный».

Добавление задачи: принимаем string_view, сохраняем string

#include <string>
#include <string_view>
#include <vector>

struct Task {
    std::string title;
    bool done = false;
};

void add_task(std::vector<Task>& tasks, std::string_view title) {
    tasks.push_back(Task{std::string(title), false}); // создаём владеющую копию
}

Контракт простой: вызывающий может передать хоть литерал, хоть std::string, хоть кусок строки. Мы внутри делаем копию и больше ни от кого не зависим.

Печать задач: работаем с владением

#include <iostream>
#include <vector>

struct Task {
    std::string title;
    bool done = false;
};

void print_tasks(const std::vector<Task>& tasks) {
    for (std::size_t i = 0; i < tasks.size(); ++i) {
        std::cout << i << ". [" << (tasks[i].done ? 'x' : ' ') << "] "
                  << tasks[i].title << '\n';
    }
}

Парсинг команды: string_view живёт только внутри обработки строки

Допустим, у нас команды такие:

• /add Buy milk
• /done 0
• /list

Мы читаем строку целиком как std::string line, а дальше внутри обработки создаём std::string_view на неё.

#include <iostream>
#include <string>
#include <string_view>

std::string_view trim_left(std::string_view s) {
    while (!s.empty() && s.front() == ' ') {
        s.remove_prefix(1);
    }
    return s;
}

int main() {
    std::string line = "   /add Buy milk";
    std::string_view v = trim_left(line);

    std::cout << v << '\n'; // /add Buy milk
}

Важно: v валиден только пока жив line и пока line не модифицируется так, что переедет буфер. Но здесь line живёт в текущем scope, и мы используем v сразу — это нормальный сценарий.

6. Owner живёт и не ломает буфер под view

С std::string и std::vector есть дополнительная хитрость: даже если объект-владелец жив, он может изменить внутренний буфер (например, при push_back, +=, reserve, insert). А view хранит адрес на старый буфер. Итог — владелец жив, а view уже указывает «в прошлое».

Опасность: держим string_view и меняем std::string

#include <iostream>
#include <string>
#include <string_view>

int main() {
    std::string s = "abc";
    std::string_view sv = s;

    s += "defghijklmnopqrstuvwxyz"; // может перевыделить буфер
    std::cout << sv << '\n';        // UB, если буфер переехал
}

Это особенно коварно тем, что иногда строка не переедет (например, из-за small string optimization), и вам покажется, что «всё нормально». А потом поменяете длину текста — и внезапно всё сломается.

Аналогично со span и vector

#include <iostream>
#include <span>
#include <vector>

int main() {
    std::vector<int> v{1, 2, 3};
    std::span<const int> sp{v.data(), v.size()};

    v.push_back(4);              // может перевыделить память
    std::cout << sp[0] << '\n';   // UB, если перевыделение произошло
}

Из этого вытекает практическая привычка: если вам нужен std::span на вектор, обычно логично сначала «дособрать» вектор (все push_back/insert/reserve), и только потом брать span и передавать дальше.

7. Полезные нюансы: хранение view и мини-памятка

Что делать, если всё-таки хочется хранить view

Иногда хочется, чтобы структура хранила «срез» данных без копий. В рамках нашего курса базовое правило будет простым: не храните view в полях, пока не научитесь гарантировать владельца на уровне архитектуры (а это отдельное искусство).

В прикладном коде для новичка есть три здоровых альтернативы.

• Вместо хранения std::string_view храните std::string. Да, копия. Зато модель данных становится честной: если задача хранит заголовок — она его и хранит.
• Вместо хранения std::span храните std::vector или std::array (в зависимости от того, нужен ли динамический размер). Это владение, оно не исчезает из-под ног.
• Если очень хочется избежать копии, чаще всего правильный путь — хранить индекс/ID или другой «ключ», а данные держать в одном месте-владельце. Но это уже момент, где легко переусложнить. Сегодня наша цель — безопасность и очевидность.

Мини-памятка для TaskTracker: где view уместен, а где нет

Чтобы связать тему прямо с нашим приложением, зафиксируем: в TaskTracker std::string_view полезен для обработки входных строк, команд и токенов, потому что там мы часто хотим «посмотреть кусок строки» без лишних копий. Но как только мы добавляем задачу в список, мы обязаны превратить этот кусок в std::string и сохранить уже владеющую копию.

Ниже — маленький «правильный» фрагмент обработки команды /add, который соблюдает оба правила дня.

#include <string>
#include <string_view>
#include <vector>

struct Task {
    std::string title;
    bool done = false;
};

void add_task(std::vector<Task>& tasks, std::string_view title) {
    tasks.push_back(Task{std::string(title), false});
}

void handle_add(std::vector<Task>& tasks, std::string_view line_after_cmd) {
    // line_after_cmd — view на исходную строку ввода, живёт только в рамках обработки
    add_task(tasks, line_after_cmd); // внутрь tasks попадёт копия (владение)
}

8. Типичные ошибки

Ошибка №1: “view как оптимизация по умолчанию” в полях структур.
Очень частая история: студент узнаёт про std::string_view, видит «о, без копий!», и начинает хранить string_view в моделях (Task, User, Product). Это почти гарантированно приводит к dangling, потому что поля живут долго, а источники строк часто оказываются временными или локальными. Лечится просто: модель должна владеть тем, что она хранит, а view использоваться для чтения «на входе».

Ошибка №2: создание view от временного объекта (особенно “в одну строку”).
Запись вроде std::string_view sv = std::string("hi"); выглядит компактно и «красиво», но это ловушка: временный владелец уничтожается в конце строки. В итоге sv указывает на память, которая уже не обязана содержать текст. Если нужен владелец — делайте std::string s = "hi"; и только потом std::string_view sv = s;.

Ошибка №3: “владелец жив, значит view безопасен”, игнорируя перевыделения.
Со строками и векторами опасность не только в уничтожении объекта, но и в изменении буфера. s += ... и v.push_back(...) могут перевыделить память, и тогда старые string_view/span становятся висячими даже при живом владельце. Поэтому view обычно берут на короткое время и не держат через модификации владельца.

Ошибка №4: возврат view/ссылки на данные, созданные внутри функции.
Возврат std::string_view на локальную std::string или std::span на локальный std::vector — почти гарантированный dangling. Новичков спасает правило: если данные созданы внутри — возвращайте владеющий тип по значению. Это делает контракт безопасным и очевидным.

Ошибка №5: “сейчас же использую” как оправдание.
Иногда кажется: «ну я же сразу разыменую указатель/ссылку/прочитаю view». Но если dangling появляется сразу после return, «сразу» уже не спасает: объект уничтожен прямо в момент выхода из функции. Время жизни нужно анализировать отдельно от того, насколько вы торопитесь использовать значение.

1

Задача

C++ SELF, 47 уровень, 2 лекция

Недоступна

Метка команды

Метка команды

Открыть

1

Задача

C++ SELF, 47 уровень, 2 лекция

Недоступна

Срез пробелов

Срез пробелов

Открыть

1

Задача

C++ SELF, 47 уровень, 2 лекция

Недоступна

Список заголовков

Список заголовков

Открыть

1

Задача

C++ SELF, 47 уровень, 2 лекция

Недоступна

Мини статистика

Мини статистика

Открыть