Лекции

Разбираем, почему даже с std::shared_ptr можно получить утечку памяти без единого delete: как образуется цикл владения, почему счётчики ссылок не падают до 0, как диагностировать проблему через деструкторы и почему “чинить” это ручными reset() — опасная заплатка. На примере связки Task ↔ Column подводим к идее невладеющих ссылок и роли std::weak_ptr.

Разбираем, зачем нужен std::weak_ptr в C++: как хранить «ссылку для навигации» без владения, почему циклы из std::shared_ptr приводят к утечкам, как безопасно получать доступ через lock(), и как проектировать связи «владеет/наблюдает» на примере модели Project– Task.

Разбираем практическое правило владения в C++: почему по умолчанию стоит выбирать std::unique_ptr, в каких случаях совместное владение через std::shared_ptr действительно оправдано, зачем нужен std::weak_ptr для разрыва циклов, и как «читать» роли ссылок (владелец/совладелец/наблюдатель) прямо по типам в API. В конце — таблица выбора, мини-схема и типичные ошибки.

Разбираем, какие special member functions компилятор C++ генерирует автоматически и при каких условиях это происходит: конструктор по умолчанию T(), деструктор ~T(), копирующий конструктор T(const T&) и копирующее присваивание operator=. Отдельно обсуждаем, почему операции могут стать implicitly deleted (например, из‑за поля std::unique_ptr) и как это связано с моделью владения ресурсами.

Разбираем практический смысл Rule of Zero: как проектировать «value-like» типы без самописных деструкторов и копирования, полагаясь на RAII-поля вроде std::string и std::vector. Обсуждаем, почему владение через * ( T*) и ручные new/ delete часто ведут к ошибкам, и как честная семантика владения выражается через std::unique_ptr и std::shared_ptr.