История capture this
#опытным

Проследим историю захвата this в лямбду сквозь стандарты С++, там есть на что посмотреть.

С++11

Появились лямбды и в них можно захватывать this как явно, так и неявно через параметры захвата по-умолчанию. Во всех случаях захватывается &(*this) то есть указатель на текущий объект:

struct Foo {
  int m_x = 0;

  void func() {
    int x = 0;
    
    //Explicit capture 'this'
    [this]() { /*access m_x and x*/ }();
    
    //Implcit capture 'this'
    [&]() { /*access m_x and x*/ }();
    
    //Redundant 'this'
    [&, this]() { /*access m_x and x*/ }();
    
    //Implcit capture 'this'
    [=]() { /*access m_x and x*/ }();
    
    //Error
    [=, this]() { }();
  }
};

Однако не было адекватного способа захватить объект по значению aka скопировать его в лямбду.

С++14

Появилась инициализация в захвате, поэтому стал реальным захват объекта по значению:

struct Foo {
  int m_x = 0;

  void func() {
    [copy=*this]() mutable {
        copy.m_x++;
    }();
  }
};

В остальном все осталось также.

С++17

Появился захват объекта по значению! Захват по значению может быть очень важно для асинхронных операций, которые откладывают выполнение лямбд:

struct Processor {
 //Some state data..

  std::future<void> process(/*args*/) {
    //Pre-process...
    //Do the data processing asynchronously
    return
    std::async(std::launch::async,
        [=](/*data*/){
    /*
      Runs in a different thread.
     'this' might be invalidated here
    */
    
    //process data
    });
  }
};

auto caller() {
 Processor p;
 return p.process(/*args*/);
} 

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

struct Processor {
  std::future<void> process(/*args*/) {
    return
    std::async(std::launch::async,
        [*this](/*data*/){
    /*
      Runs in a different thread.
     'this' might be invalidated here
    */
    
    //process data
    });
  }
};

В этом случае в лямбде будет храниться копия объекта и все методы будут обращаться к этому скопированному объекту.

С++20

С появлением захвата this по значению стала очень путающей семантика неявного захвата. Что reference capture &, что value capture =, по факту захватывали текущий объект по ссылке. И ничто неявно не захватывало this по значению.

Изначально в 20-м стандарте эту проблему хотели решить, просто запретив неявный захват this в любом случае. Но посидели и поняли, что для ссылочного захвата по умолчанию семантика неявного захвата ссылки на объект(чем отдаленно явняется this) корректна. А вот для захвата по значению - нет.

Поэтому начиная с С++20 мы не можем неявно захватывать this в default capture by value:

struct Bagel {
  int x = 0;
  void func() {
    //OK until C++20. Warning in C++20.
    [=]() { std::cout << x; }();
    
    //Error/warning until C++20. OK in C++20.
    [=, this]() { std::cout << x; }();
  }
};

Оставлю в картинке под постом инфографику по изменениям в стандартах относительно захвата this.

Know the history. Stay cool.

#cpp11 #cpp14 #cpp17 #cpp20

Правильно захватываем по ссылке объект в лямбду
#опытным

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

struct Task {
    int id;

    std::function<void()> GetNotifier() {
        return [&]{
            std::cout << "notify " << id << std::endl;
        };
    }
};

int main() {
    auto notify = Task { 5 }.GetNotifier();
    notify();
}

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

Тут бы шаред поинтер использовать. Но втупую его заюзать тоже ничем не поможет:

struct Task {
    int id;

    std::function<void()> GetNotifier() {
        return [curr = std::shared_ptr<Task>(this)]{
            std::cout << "notify " << curr->id << std::endl;
        };
    }
};

int main() {
    auto notify = Task { 5 }.GetNotifier();
    notify();
}

Да, мы создали из this шареный указатель, но его контрольный блок никак не учитывает оригинальный объект! curr будет думать, что только он и его копии будут владеть объектом, а оригинальный объект просто уничтожится и curr будет ссылаться на невалидный объект. Получили то же самое UB.

Что делать?

Использовать миксин C++11 std::enable_shared_from_this. Это базовый CRTP класс, который предоставляет метод shared_from_this(). Если вы обернете исходный объект в std::shared_ptr, то метод shared_from_this возвращает копию объекта умного указателя, в котором находился исходный объект. Эта копия будет разделять контрольный блок с оригинальным объектом, поэтому пока жива хоть одна копия, исходный объект не разрушится. Выглядит это так:

struct Task : std::enable_shared_from_this<Task> {
    int id;

    std::function<void()> GetNotifier() {
        // Захватываем shared_ptr на текущий объект
        return [self = shared_from_this()] {
            std::cout << "notify " << self->id << std::endl;
        };
    }
};

int main() {
    auto notify = std::make_shared<Task>(5)->GetNotifier();
    notify();  // Теперь безопасно - объект не будет уничтожен
}

В первой строчке main происходит много вещей:
1️⃣ Создается объект класса Task и оборачивается во временный объект умного указателя.

2️⃣ Вызывается метод GetNotifier у объекта внутри временного умного указателя, из которого возвращается лямбда с захваченной копией временного объекта.

3️⃣ До перехода к следующей строчке временный объект, созданный через make_shared, разрушается.

Но ничего страшного не происходит, потому что notify хранит в себе копию временного объекта умного указателя, а значит тебе эта лямбда владелец исходного объекта Task{5}. Поэтому при вызове этой лямбды никакого Ub и провисания ссылки нет.

Вообще, наверное пора рассказывать про CRTP, миксины и прочие нечисти шаблонов в С++. Если хотите такого, то жмякните лайкосик, а с нам посты по этим темам.

Watch your lifetime. Stay cool.

#template #cpp11

​​Динамический полиморфизм. std::function
#новичкам

В прошлом посте поговорили, что динамический полиморфизм реализуется не только через иерархии классов и виртуальные методы.

Есть другой прекрасный инструмент - std::function. Это обертка над всеми callable объектами, которая позволяет их единообразоно вызывать. Никаких иерархий, только функциональные объекты.

void Worker(std::deque<std::function<void()>>& tasks) {
  while (!tasks.empty()) {
    auto task = std::move(tasks.front());
    tasks.pop_front();
    task(); // call callable
  }
}

void Producer1(const std::string& bucket, const std::vector<std::string>& paths, 
                const std::shared_ptr<S3Client>& client, std::deque<std::function<void()>>& tasks) {
  for (const auto& path: paths)
    tasks.emplace_back([&]{
      client_->Upload(bucket, path);
      std::cout << "Uploaded: " << bucket << ", path " << path << std::endl;
    });
}

void Producer2(const std::vector<std::string>& paths, std::deque<std::function<void()>>& tasks) {
  for (const auto& path: paths)
    tasks.emplace_back([&]{
      std::remove(path.c_str());
          std::cout << "Deleted: " << path << std::endl;
    });
}

Теперь в очереди хранятся какие-то вызываемые объекты. Воркеру не важно, что это за объекты. Главное, что продюсеры могут разные функциональные объекты положить в один и тот же контейнер, попутно обернув их в std::function и тем самым полностью обезличив их. А легитимность такого мува достигается за счет того, что эти объекты имеют единый интерфейс - их можно вызвать без аргументов и не получить никакого возвращаемого значения.

Уже сейчас можно заметить, что для динамического полиморфизма нужно какого-то рода type erasure(стирание типов). Структура, которая хранит полиморфные объекты, не должна иметь полную информации о конкретном типе этих объектов. Объекты лишь должны иметь какой-то общий интерфейс. И тогда тип неважен: мы можем оперировать объектами через этот общий интерфейс.

std::function довольно интересно внутри устроен. После верхнеуровневого разговора про все полиморфизмы, вернемся к нему.

Но в плюсах есть еще много примеров полиморфизма времени выполнения, о которых поговорим в следующий раз.

Extract common traits. Stay cool.

#cpp11

​​std::getenv
#новичкам

Переменные окружения - это пары "ключ-значение", которые хранятся в операционной системе и доступны всем процессам. Они часто используются для:

- Конфигурации приложений
- Хранения чувствительных данных (паролей, ключей API)
- Управления поведением программ

Самый банальный пример - PATH. В этой переменной окружения находится список путей для поиска исполняемых файлов системой. Добавив путь к своей утилите в эту переменную, вы сможете ее запускать без указания полного пути.

Или например, более приближеный к плюсам пример, LD_LIBRARY_PATH. Это список путей, в котором линкер ищет указанные при линковке библиотеки.

И мы можем прочитать из плюсового кода переменные окружения с помощью С++11 функции std::getenv:

#include <cstdlib>

char* std::getenv(const char* name);

Это скоммунизженная из Сей функция, которая принимает имя переменной окружения и возвращает ее содержимое. Если искомой переменной не существует, возвращается nullptr.

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

При запуске программы ОС копирует переменные окружения, видимые родительскому процессу, внутрь программы и таким образом они окружение программы перестает зависеть от внешнего мира.

Допустим, пишите вы какой-нибудь свой клиент-сервер на Boost.Asio. Хочется конфигурировать клиента адресом и портом сервера извне, чтобы иметь возможность по-разному запускать клиента локально и, допустим, через docker-compose. Конфиг и его парсилку писать довольно муторно, а адекватную парсилку аргументов командной строки - еще сложнее. Даже если использовать готовые решения в виде json парсера и boost.program_options.

Вместо этих решений можно передавать креды подключения к серверу через переменную окружения:

#include <boost/asio.hpp>
#include <iostream>
#include <cstdlib>

using boost::asio::ip::tcp;

int main() {
    try {
        // HERE
        const char* host = std::getenv("SERVER_HOST");
        const char* port = std::getenv("SERVER_PORT");

        if (!host || !port) {
            std::cerr << "Please set SERVER_HOST and SERVER_PORT environment variables\n";
            return 1;
        }

        boost::asio::io_context io_context;

        // Создаем и соединяем сокет
        tcp::socket socket(io_context);
        tcp::resolver resolver(io_context);
        boost::asio::connect(socket, resolver.resolve(host, port));

        // Отправляем тестовое сообщение
        std::string message = "Hello from Boost.Asio client!\n";
        boost::asio::write(socket, boost::asio::buffer(message));

        // Читаем ответ (до символа новой строки)
        boost::asio::streambuf response;
        boost::asio::read_until(socket, response, '\n');

        // Выводим ответ
        std::istream is(&response);
        std::string reply;
        std::getline(is, reply);
        std::cout << "Server replied: " << reply << std::endl;

    } catch (std::exception& e) {
        std::cerr << "Exception: " << e.what() << "\n";
        return 1;
    }

    return 0;
}

Всего две строчки и никакой мороки! Очень удобная и полезная функция.

Explore your enviroment. Stay cool.

#cpp11

​​Недостатки std::make_shared. Кастомный new и delete
#новичкам

В этой небольшой серии будем рассказывать уже о различных ограничениях при работе с std::make_shared.

И начнем с непопулярного.

Внутри себя она создает объект с помощью ::new. Это значит, что если вы для своего класса переопределяете операторы работы с памятью, то make_shared не будет учитывать это поведение, а вы будете гадать, почему не видите нужных спецэффектов:

class A {
public:
    void *operator new(size_t) {
        std::cout << "allocate\n";
        return ::new A();
    }

    void operator delete(void *a) {
        std::cout << "deallocate\n";
        ::delete static_cast<A *>(a);
    }
};

int main() {
    const auto a =
        std::make_shared<A>();  // ignores overloads
    //const auto b =
    //    std::shared_ptr<A>(new A);  // uses overloads
}
// OUTPUT:
// Пусто!

В общем, если нужный кастомный менеджент памяти, то std::make_shared - не ваш бро.

Customize your solutions. Stay cool.

#cppcore #cpp11 #memory

Недостатки std::make_shared. Непубличные конструкторы
#новичкам

std::make_shared - это сторонний код по отношению к классу, объект которого он пытается создать. Поэтому на принципиальную возможность создания объекта влияет спецификатор видимости конструктора.

Если конструктор публичный - проблем нет, просто вызываем std::make_shared.

Но things get trickier, если конструктор непубличный. Его тогда не может вызывать никакой чужой код.

Для определенности примем, что конструктор приватный. Это может делаться по разным причинам. Например у нас есть необходимость в создании копий std::shared_ptr, в котором находится исходный объект this. Тогда класс надо унаследовать от std::enable_shared_from_this и возвращать из фабрики std::shared_ptr. Если создавать объект любым другим путем, то будет ub. Поэтому, как заботливые нянки, помогает пользователям не изменять количество отверстий в ногах:

struct Class: public std::enable_shared_from_this<Class> {
  static std::shared_ptr<Class> Create() {
    // return std::make_shared<Class>(); // It will fail.
      return std::shared_ptr<Class>(new Class);
  }
private:
  Class() {}
};

Использовать make_shared здесь не выйдет. Хоть мы и используем эту функцию внутри метода класса, это не позволяет ей получить доступ к приватным членам.

В таком случае мы просто вынуждены использовать явный конструктор shared_ptr и явный вызов new.

А как вы знаете, в этом случае будут 2 аллокации: для самого объекта и для контрольного блока. Если объект создается часто, то это может быть проблемой, если вы упарываетесь по перфу.

Hide your secrets. Stay cool.

#cppcore #cpp11

​​Недостатки std::make_shared. Кастомные делитеры
#новичкам

Заходим на cppreference и видим там такие слова:

This function may be used as an alternative to std::shared_ptr<T>(new T(args...)).

Также видим ее сигнатуру:

template< class T, class... Args >
shared_ptr<T> make_shared( Args&&... args );

И понимаем, что make_shared не предоставляет возможности указывать кастомный делитер. Все аргументы функции просто перенаправляются в конструктор шареного указателя.

Опустим рассуждения об оправданных кейсах применения кастомных делитеров для шареных указателей. Можете рассказать о своих примерах из практики в комментариях.

Мы же попытаемся ответить на вопрос: "А почему нельзя указать делитер?".

Одной из особенностей make_shared является то, что она аллоцирует единый отрезок памяти и под объект, и под контрольный блок. И использует базовый оператор new для этого.

Получается и деаллокация для этих смежных частей одного отрезка памяти должна быть совместная, единая и через базовый оператор delete.

Если бы мы как-то хотели бы встроить делитер в эту схему, получился бы конфликт: делитер хочет удалить только объект, но им придется пользоваться и для освобождения памяти под контрольный блок. Это просто некорректное поведение.

Да и скорее всего, если вас устраивает помещать объект в шареный указатель вызовом дефолтного new, то устроит и использование дефолтного delete. Поэтому эта проблема тесно связана с проблемой из первой части серии, но не добавляет особых проблем сверх этого.

Customize your solutions. Stay cool.

#cppcore #cpp11 #memory

​​Какой день будет через месяц?
#новичкам

Работа со временем в стандартных плюсах - боль. Долгое время ее вообще не было. chrono появилась так-то в С++11. Но и даже с ее появлением жить стало лишь немногим легче.

Например, простая задача: "Прибавить к текущей дате 1 месяц".

В С++11 у нас есть только часы и точки на временной линии. Тут просто дату-то получить сложно. Есть конечно сишная std::localtime, можно мапулировать отдельными полями std::tm(днями, минутами и тд), но придется конвертировать сишные структуры времени в плюсовые, да и можно нарваться на трудноотловимые ошибки, если попытаться увеличить на 1 месяц 30 января.

Как прибавить к дате месяц? +30 дней или +1 месяц не канает. А если февраль? А если високосный год?

В общем стандартного решения нет... Или есть?

В С++20 в библиотеку chrono завезли кучу полезностей. А в частности функционал календаря. Теперь мы можем манипулировать отдельно датами и безопасно их изменять.

Например, чтобы получить сегодняшнюю дату и красиво ее вывести на консоль достаточно сделать следующее:

std::chrono::year_month_day current_date =
        std::chrono::floor<std::chrono::days>(
            std::chrono::system_clock::now());
    std::cout << "Today is: " << current_date << '\n';
// Today is: 2025-09-10

Появился прекрасный класс std::chrono::year_month_day, который отражает конкретно дату. И его объекты замечательно сериализуются в поток.

Если вам нужно задать определенный формат отображения - не проблема! Есть std::format:

std::cout << "Custom: "
              << std::format("{:%d.%m.%Y}", current_date)
              << '\n';
// Custom: 10.09.2025

С помощью std::chrono::year_month_day можно удобно манипулировать датами и, главное, делать это безопасно. Что будет если я к 29 января прибавлю месяц?

auto date = std::chrono::year_month_day{
        std::chrono::year(2004), std::chrono::month(1), std::chrono::day(29)};
std::cout << "Date: " << date << "\n";

std::chrono::year_month_day next_month = date + std::chrono::months{1};
std::chrono::year_month_day next_year_plus_month =
    date + std::chrono::years{1} + std::chrono::months{1};

std::cout << "Next month: " << next_month << "\n";
std::cout << "Next year plus month: " << next_year_plus_month << "\n";

// OUTPUT:
// Date: 2004-01-29
// Next month: 2004-02-29
// Next year plus month: 2005-02-29 is not a valid date

А будет все хорошо, если год високосный. Но если нет, то библиотека нам явно об этом скажет.

В общем, крутой фиче-сет, сильно облегчает работу со стандартными временными точками.

Take your time. Stay cool.

#cpp11 #cpp20

Идиома IILE
#опытным

Неплохой практикой написания кода является определение переменных, которые не изменяются, как const. Это позволяет коду был более экспрессивным, явным, а также компилятор в этом случае может чуть лучше рассуждать о коде и оптимизировать. И это не требует ничего сложного:

const int myParam = inputParam * 10 + 5;
// or
const int myParam = bCondition ? inputParam * 2 : inputParam + 10;

Но что делать, если переменная по сути своей константа, но у нее громоздская инициализация на несколько строк?

int myVariable = 0; // this should be const...

if (bFirstCondition)
    myVariable = bSecondCindition ? computeFunc(inputParam) : 0;
else
    myVariable = inputParam * 2;

// more code of the current function...
// and we assume 'myVariable` is const now

По-хорошему это уносится в какую-нибудь отдельную функцию. Но тогда теряется контекст и нужно будет прыгать по коду.

Хочется и const сделать, и в отдельную функцию не выносить. Кажется, что на двух стульях не усидишь, но благодаря лямбдам мы можем это сделать!

Есть такая идиома IILE(Immediately Invoked Lambda Expression). Вы определяете лямбду и тут же ее вызываете. И контекст сохраняется, и единовременность инициализации присутствует:

const int myVariable = [&] {
    if (bFirstContidion)
        return bSecondCondition ? computeFunc(inputParam) : 0;
    else
       return inputParam * 2;
}(); // call!

Пара лишних символов, зато проблема решена.

Тут есть одно "но". Вроде все хорошо, но немного напрягает, что все это можно спутать с простым определением лямбды, если не увидеть скобки вызова в конце.

Тоже не беда! Используем std::invoke:

const int myVariable = std::invoke([&] {
    if (bFirstContidion)
        return bSecondCondition ? computeFunc(inputParam) : 0;
    else
       return inputParam * 2;
});

Теперь мы четко и ясно видим, что лямбда вызывается. В таком виде прям кайф.

Эту же технику можно использовать например в списке инициализации конструктора, например, если нужно константное поле определить(его нельзя определять в теле конструктора).

Be expressive. Stay cool.

#cpp11 #cpp17 #goodpractice

​​Гарантия отсутствия исключений
#новичкам

Переходим к самой сильной гарантии - отсутствие исключений.

В сам язык С++(new, dynamic_cast), и в его стандартную библиотеку в базе встроены исключения. Поэтому писать код без исключений в использованием стандартных инструментов практически невозможно. Вы конечно можете использовать nothrow new и написать свой вариант стандартной библиотеки и других сторонних решений. И кто-то наверняка так делал. Но в этом случае разработка как минимум затянется, а как максимум вы бросите это гиблое дело.

Поэтому повсеместно предоставлять nothow гарантии с использованием стандартных инструментов не всегда реалистично.

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

Но для начала проясним термины.

Под гарантией отсутствия исключений подразумевается обычно 2 понятия: nothrow и nofail.

nothrow подразумевает отсутствие исключений, но не отсутствие ошибок. Говорится, что ошибки репортятся другими средствами(в основном через глобальное состояние, потому что деструктор ничего не возвращает) или полностью скрываются и игнорируются.

Примером сущностей с nothrow гарантией является деструкторы. С С++11 они по-умолчанию помечены noexcept. В основном это сделано для того, чтобы при раскрутке стека не получить double exception.
Но деструкторы могу фейлиться. Просто никаких средств, кроме глобальных переменных для репорта ошибок невозможно использовать. Они ведь ничего не возвращают, а исполняются скрытно от нас(если вы используете RAII конечно).

nofail же подразумевает полное отсутствие ошибок. nofail гарантия ожидается от std::swap, мув-конструкторов классов и других функций с помощью которых достигается строгая гарантия исключений.

Например в swap-идиоме std::swap и мув-конструкторы используются для определения небросающего оператора присваивания.

nofail гарантиями также должны обладать функторы-коллбэки модифицирующих алгоритмов. std::sort не предоставляет никаких гарантий на состояние системы, если компаратор бросит эксепшн.

В языке в целом эти гарантии обеспечиваются ключевым словом noexcept. При появлении этой нотации компилятор понимает, что для этой функций не нужно генерировать дополнительный код, необходимый для обработки исключений. Но у этого есть своя цена: если из noexcept функции вылетит исключение, то сразу же без разговоров вызовется std::terminate.

Provide guarantees. Stay cool.

#cppcore #cpp11

​​Недостатки std::make_shared. Деаллокация
#новичкам

Представляете, забыл выложить один важный пост из серии про недостатки std::make_shared. Затерялся он в пучине заметок. Исправляюсь.

В предыдущих сериях:
Кастомный new и delete
Непубличные конструкторы
Кастомные делитеры

А теперь поговорим про деаллокацию.

В этом посте мы рассказали о том, что std::make_shared выделяет один блок памяти под объект и контрольный блок. 1 аллокация вместо 2-х = большая производительность. Однако у монеты всегда две стороны.

Что происходит с объектом и памятью при работе с shared_ptr напрямую через конструктор?

Отдельно выделяется память и конструируется разделяемый объект с помощью явного вызова new, отдельно выделяется память и конструируется контрольный блок.

Деструктор разделяемого объекта и освобождение памяти для него происходит ровно в тот момент, когда счетчик сильных ссылок становится нулем. При этом контрольный блок остается живым до момента уничтожения последнего std::weak_ptr:

void operator delete(void *ptr) noexcept {
    std::cout << "Global delete " << std::endl;
    std::free(ptr);
}

class MyClass {
public:
    ~MyClass() {
        std::cout << "Деструктор MyClass вызван.\n";
    }
};

int main() {
    std::weak_ptr<MyClass> weak;

    {
        std::shared_ptr<MyClass> shared(new MyClass());
        weak = shared;
        std::cout
            << "shared_ptr goes out of scope...\n";
    }  // Here shared is deleting

    std::cout << "weak.expired(): " << weak.expired()
              << '\n';
    weak.reset();

    std::cout << "All memory has been freed!\n";
}
// OUTPUT:
// shared_ptr goes out of scope...
// Dtor MyClass called.
// Global delete 
// weak.expired(): 1
// Global delete 
// All memory has been freed!

Мы переопределили глобальный delete, чтобы увидеть момент освобождения памяти на разных этапах.

Деструктор и delete для разделяемого объекта вызываются ровно в момент выхода объекта shared из своего скоупа. Тем не менее weak_ptr жив, он знает, что объекта уже нет, но своим наличием продлевает время жизни контрольного блока. После ресета weak ожидаемо происходит деаллокация блока.

Что же происходит при использовании std::make_shared? В какой момент освобождается вся выделенная память?

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

void operator delete(void *ptr) noexcept {
    std::cout << "Global delete " << std::endl;
    std::free(ptr);
}

class MyClass {
public:
    ~MyClass() {
        std::cout << "Деструктор MyClass вызван.\n";
    }
};
int main() {
    std::weak_ptr<MyClass> weak;

    {
        auto shared = std::make_shared<MyClass>();
        weak = shared;

        std::cout << "shared_ptr goes out of scope...\n";
    }  // shared уничтожается здесь

    std::cout << "weak.expired(): " << weak.expired()
              << '\n';  // true
    weak.reset();

    std::cout << "All memory has been freed!\n";
}
// shared_ptr goes out of scope...
// Dtor MyClass called.
// weak.expired(): 1
// Global delete 
// All memory has been freed!

Отметьте вызов деструктора после выхода из скоупа, но при этом память еще не освобождается. Она делает это только после reset и уничтожении последней слабой ссылки.

Учитывайте эти особенности, когда используете weak_ptr(например в кэше или списках слушателей).

Consider both sides of the coin. Stay cool.

#cpp11 #memory