Лекции

Разбираем, почему std::string_view — это «вид» на чужую память (адрес + длина), а не строка, и как из этого вырастают классические ошибки времени жизни: view из временной std::string, view на результат substr(), возврат string_view из функций, хранение view в полях моделей и использование view после модификации исходной строки. В конце собираем безопасный стиль: принимаем std::string_view, но храним std::string, и фиксируем чек-лист/схему принятия решения.

Разбираем, почему std::span — это невладеющий view на память, и как обычный рост std::vector (через push_back/ emplace_back) может вызвать reallocation, изменить адрес data() и превратить старый span в dangling (и, как следствие, в UB). Показываем типичные грабли: инвалидирование при перевыделении, «устаревший» размер, разрушение элементов через pop_back/ erase, и формулируем безопасный стиль: span как параметр функции, а не как долгоживущее состояние.

Разбираем практичную модель owner/ view в C++: почему std::string_view, std::span, указатели и ссылки не владеют данными, как появляются dangling и UB, какие два правила защищают время жизни (owner живёт дольше view и не хранить view в полях без гарантий), а также как спроектировать API (value, const &, view) на примере мини‑проекта TaskTracker.

Разбираем «мини‑гигиену» производительности в C++ как инструмент стабилизации эксперимента при расследовании ошибок памяти: почему лишние копии и переезды мешают воспроизводимости, как std::vector ведёт себя при push_back и reallocation, чем отличаются reserve и resize, а также как «честные сигнатуры» (передача по const &, std::string_view, std::span) уменьшают шум в отчётах санитайзеров и помогают быстрее выделить первопричину.

Практический маршрут расследования багов в C++: как превратить «иногда падает» в детерминированный repro, как минимизировать сценарий до MRE, как фиксировать артефакты расследования и строить регресс‑барьер через assert и self_check(). На примере std::vector, висячих указателей ( Task *) и переезда памяти при push_back показываем, как мыслить инженерно и проверяемо.