🔥 Ловим баги в C++ на лету с помощью AddressSanitizer (ASan)

Если valgrind — это медленный, но подробный детектив, то ASan — это охрана, которая ловит баги прямо во время исполнения. Быстро, точно, удобно.


💡 Что такое ASan?
Это часть компилятора (clang или gcc), которая вставляет дополнительные проверки в бинарник. Работает во время запуска, ловит:

- выход за границы массива,
- use-after-free,
- double free,
- утечки памяти (с флагом LeakSanitizer).


👨‍💻 Пример:

// asan_example.cpp
#include <iostream>

int main() {
    int* arr = new int[5];
    arr[10] = 42; // выход за границу
    delete[] arr;
    return 0;
}

⚙️ Компиляция с ASan:

g++ -fsanitize=address -g asan_example.cpp -o app

🚀 Запуск:

./app

📄 Результат:

==12345==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000050
READ of size 4 at 0x602000000050 thread T0
    #0 0x... in main asan_example.cpp:6

📌 Плюсы ASan:
- Мгновенная обратная связь;
- Прост в использовании;
- Отлично работает с CI (GitHub Actions, GitLab CI и т.д.);
- Поддерживает LeakSanitizer (-fsanitize=leak).

📉 Минусы:
- Увеличивает размер бинарника;
- Иногда мешает оптимизациям;
- Не ловит всё (например, утечки в сторонних lib без debug info).


🔧 Совет:
Запускай тесты с -fsanitize=address в debug-сборках. Это бесплатно и спасает от кучи головной боли в будущем.


🧵 Используешь ли ты ASan в своих проектах? Или только valgrind? Пиши в комментах👇

➡️ @cpp_geek

🚀 Сегодня я покажу вам простой, но очень полезный приём в C++: как элегантно управлять временем жизни ресурса с помощью std::unique_ptr и кастомного deleter'а.

📌 Задача: у нас есть не-C++ ресурс, например, FILE* из stdio.h. Мы хотим, чтобы он автоматически закрывался, как только выходит из области видимости.

Вместо ручного вызова fclose, используем std::unique_ptr с кастомным deleter'ом:

#include <memory>
#include <cstdio>

int main() {
    // Кастомный deleter для FILE*
    auto fileDeleter = [](FILE* f) {
        if (f) {
            std::puts("Файл закрывается автоматически!");
            std::fclose(f);
        }
    };

    // Умный указатель с кастомным deleter'ом
    std::unique_ptr<FILE, decltype(fileDeleter)> file(std::fopen("data.txt", "r"), fileDeleter);

    if (!file) {
        std::perror("Не удалось открыть файл");
        return 1;
    }

    // Файл будет автоматически закрыт в конце блока main()
}

💡 Такой подход безопаснее, чем fopen/fclose, особенно в реальных проектах с множеством return'ов и исключениями. А главное — код остаётся чистым и идиоматичным.

🔥 А вы используете unique_ptr с кастомным deleter’ом в своём коде? Поделитесь, для чего вы его применяли!

➡️ @cpp_geek

👨‍💻 Сегодня покажу вам удобный способ, как избавиться от болей с #include в больших C++ проектах.

Когда проект растёт, количество инклудов становится пугающим. Компиляция тормозит, зависимости запутаны, порядок подключения начинает влиять на поведение программы… Знакомо?

📌 Решение — Precompiled Headers (PCH).

Это не магия, а вполне рабочая практика. Всё просто:

1. Создаём файл pch.h, в котором собираем самые часто используемые инклюды:

   // pch.h
   #pragma once
   #include <iostream>
   #include <vector>
   #include <map>
   // и т.д.
   

2. Добавляем его в компиляцию с флагом:

   g++ -x c++-header pch.h -o pch.h.gch
   

3. Теперь любой другой файл, который первым инклудит pch.h, компилируется быстрее.

⚡️ Бонус: современные сборочные системы, вроде CMake, умеют работать с PCH почти автоматически. Достаточно:

target_precompile_headers(my_target PRIVATE pch.h)

🧠 Маленький совет: следите, чтобы в pch.h не попадали редко используемые или изменяющиеся файлы — иначе получите обратный эффект.

Пользовались ли вы PCH в своих проектах? Какой прирост производительности заметили?

➡️ @cpp_geek

How to: убираем типы с помощью std::decay_t

std::decay_t — один из самых полезных type traits в C++. Он имитирует процесс передачи параметра по значению, «разрушая» исходный тип.

🔄 Что именно делает decay_t?

• Убирает cv-квалификаторы
• Превращает ссылки в соответствующие типы без ссылок
• Преобразует массивы в указатели
• Преобразует функции в указатели на функции

💻 Пример:

#include <type_traits>
#include <iostream>

int main() {
    // const int& -> int
    static_assert(std::is_same_v<std::decay_t<const int&>, int>);
    
    // int[10] -> int*
    static_assert(std::is_same_v<std::decay_t<int[10]>, int*>);
    
    // void(int) -> void(*)(int)
    static_assert(std::is_same_v<std::decay_t<void(int)>, void(*)(int)>);
    
    std::cout << "All assertions passed!" << std::endl;
}

🚀 Где это используется?

• В шаблонном программировании для упрощения работы с типами
• В std::make_shared и std::make_unique для определения типа создаваемого объекта
• При написании обобщенного кода, где нужна правильная дедукция типов

🔍 И да, название «decay» («разрушение») действительно отражает суть — тип «разрушается» до базового представления!

➡️ @cpp_geek

Сейчас покажу вам простой, но очень полезный приём, как аккуратно и безопасно управлять ресурсами в C++ с помощью RAII (Resource Acquisition Is Initialization).

Когда вы работаете с ресурсами (файлы, сокеты, мьютексы и т.д.), важно не забывать освобождать их. Особенно если программа может завершиться по исключению. И вот тут RAII — наш лучший друг.

Рассмотрим пример:

#include <fstream>
#include <string>

void writeToFile(const std::string& filename, const std::string& data) {
    std::ofstream file(filename);
    if (!file) {
        throw std::runtime_error("Unable to open file");
    }
    file << data;
} // файл автоматически закрывается здесь

Мы открыли файл — и не закрыли его вручную! Почему? Потому что std::ofstream сам закроет его в своём деструкторе. Это и есть RAII в действии.

И теперь представьте: вы можете создавать свои классы с таким же поведением! Например, класс-обёртку над pthread_mutex_t или системным дескриптором.

RAII — это стиль. И это стиль надёжного кода.


➡️ @cpp_geek

🧵 Сегодня покажу вам простой способ логгировать вызовы функций в C++ — пригодится для отладки и анализа кода.

Часто бывает нужно понять, какие функции вызываются, в каком порядке и с какими параметрами. Вручную вставлять std::cout — неудобно. Вместо этого используем RAII-макрос с выводом в консоль:

#include <iostream>
#include <string>

struct FunctionLogger {
    std::string func_name;
    FunctionLogger(const std::string& name) : func_name(name) {
        std::cout << ">> Entering: " << func_name << '\n';
    }
    ~FunctionLogger() {
        std::cout << "<< Exiting: " << func_name << '\n';
    }
};

#define LOG_FUNCTION() FunctionLogger logger(__FUNCTION__)

Теперь в любой функции достаточно просто написать LOG_FUNCTION();, и вы получите автоматический лог при входе и выходе:

void do_work() {
    LOG_FUNCTION();
    // Работаем...
}

Это особенно удобно в больших проектах, когда нужно быстро локализовать ошибку или понять структуру вызовов.

Можно доработать: лог в файл, потокобезопасность, включение по флагу компиляции и т.д.

➡️ @cpp_geek

Move-семантика: где можно ловко сэкономить

Многие знают про std::move, но не всегда используют его там, где это реально ускоряет код. Простой пример — возврат локального объекта из функции:

#include <string>

std::string make_string() {
    std::string s = "Hello";
    return s; // RVO или move
}

С C++17 тут почти всегда RVO (Return Value Optimization). Но если RVO невозможен (например, возвращаем тернарный оператор), компилятор применит move:

std::string make_string(bool flag) {
    std::string a = "foo", b = "bar";
    return flag ? a : b; // тут будет move
}

А вот так можно подсказать компилятору явно:

return std::move(flag ? a : b);

Но осторожно: не делайте std::move для локальной переменной в простом return — это может сломать RVO и привести к лишнему перемещению.

Ещё полезно помнить: move не всегда бесплатный. Например, для std::vector он копирует указатель и размер, но не элементы. Для std::string — зависит от Small String Optimization: короткие строки перемещаются как копия.

Вывод: используйте std::move там, где явно хотите отдать объект, а не копировать. Но не злоупотребляйте им: компилятор с C++17 сам неплохо справляется.

➡️ @cpp_geek

RAII — твой лучший друг (и почему не стоит бояться умных указателей)

Старый добрый new / delete — это классика, но и источник утечек, крашей и боли. В современном C++ ручное управление памятью почти всегда антипаттерн.

Решение — RAII (Resource Acquisition Is Initialization): ресурсы живут ровно столько, сколько объект, который ими владеет. Ушёл объект из области видимости — ресурс освободился.

Пример с умными указателями:

#include <memory>
#include <iostream>

struct Foo {
    Foo() { std::cout << "Init\n"; }
    ~Foo() { std::cout << "Destroy\n"; }
};

void bar() {
    std::unique_ptr<Foo> p = std::make_unique<Foo>(); // RAII
    // делаем что-то
} // тут автоматически вызовется ~Foo()

Что важно знать:

* std::unique_ptr — владение в единственном числе, идеально для большинства случаев.
* std::shared_ptr — разделённое владение (но дороже по производительности).
* Никогда не делай new без обёртки — почти всегда лучше std::make_unique или std::make_shared.

RAII работает не только для памяти: файлы, мьютексы, сокеты — всё. Достаточно обернуть ресурс в класс с деструктором.

Профит: меньше багов, меньше утечек, чище код.

➡️ @cpp_geek

std::exchange — простой способ менять значения и возвращать старые

Вместо того чтобы писать руками:

auto old = value;
value = new_value;
return old;

В modern C++ есть готовый инструмент - std::exchange (C++14+).

#include <utility>
#include <string>
#include <iostream>

int main() {
    std::string s = "Hello";
    auto old = std::exchange(s, "World");

    std::cout << "old = " << old << ", s = " << s << '\n';
}

Вывод:

old = Hello, s = World

Когда полезно:

- Реализация move-конструкторов/операторов:

  MyType(MyType&& other)
      : data_(std::exchange(other.data_, nullptr)) {}
  

- Сброс состояния объектов и возвращение старого значения.
- Реализация одноразовых флагов (`once_flag` паттерн).

Плюсы:

- Одна строка вместо трёх.
- Читаемость выше — сразу видно, что мы заменяем значение и берём старое.

Помни: по умолчанию второе значение копируется/перемещается, так что это не нулевой по стоимости вызов.

➡️ @cpp_geek

std::move vs std::forward: когда и что использовать

Сегодня покажу вам коротко, чем отличаются std::move и std::forward.

- std::move(obj) — безусловно превращает объект в rvalue. После этого объект считается "пустым" для повторного использования (в рамках контракта move). Используем, когда мы точно хотим "забрать" ресурсы.

- std::forward<T>(obj) — условно делает rvalue, если изначально пришёл rvalue. То есть это "perfect forwarding" для шаблонных функций.

Пример:

#include <utility>
#include <string>
#include <iostream>

template <typename T>
void wrapper(T&& arg) {
    process(std::forward<T>(arg)); // сохраняет rvalue/lvalue-семантику
}

void process(const std::string& s) { std::cout << "Lvalue: " << s << '\n'; }
void process(std::string&& s) { std::cout << "Rvalue: " << s << '\n'; }

int main() {
    std::string str = "Hello";
    wrapper(str);               // Lvalue
    wrapper(std::move(str));    // Rvalue
}

Запомните:

- std::move - "забрать".
- std::forward - "передать как есть".

➡️ @cpp_geek