🍪 std::mem_fn vs лямбда: что быстрее и почему это не то, что ты думаешь

С точки зрения assembly при включённой оптимизации (-O2) std::mem_fn и эквивалентная лямбда дают идентичный код. Оба являются callable с inline-дружественной структурой: компилятор видит конкретный тип и инлайнит вызов.

🍿 Разница появляется в контексте стирания типов. Если callable хранится в std::function<>:

// Лямбда — захват this в замыкании
std::function<int(Foo&)> f1 = [](Foo& x) { return x.bar(); };

// mem_fn — хранит pointer-to-member
std::function<int(Foo&)> f2 = std::mem_fn(&Foo::bar);

❗️ В обоих случаях std::function выполняет type erasure — heap-аллокацию для хранения callable (если он не влезает в Small Buffer Optimization, обычно ≤16 байт). Для mem_fn размер объекта — ровно размер pointer-to-member (8-16 байт), для лямбды без захвата — 1 байт. Оба влезают в SBO.

💡 Реальная разница — читаемость и семантика. std::mem_fn явно сигнализирует «это вызов метода». Лямбда гибче, но многословнее. В алгоритмах с однотипными вызовами mem_fn лаконичнее:

std::transform(v.begin(), v.end(), out.begin(), std::mem_fn(&Widget::value)); // vs лямбда

✏️ Используй mem_fn, когда хочешь выразить «вызов конкретного метода». Лямбду — когда нужна логика внутри.


📍Навигация: Вакансии • Задачи • Собесы

Библиотека C/C++ разработчика

#под_капотом

🚀 C++23 и дальше: насколько код может стать сладким

C++23 принёс ряд долгожданных улучшений. std::expected — альтернатива исключениям для обработки ошибок в функциональном стиле. std::print вместо printf и cout. Deducing this — явный доступ к *this в методах, открывающий новые паттерны.

На горизонте C++26: static reflection позволит исследовать типы во время компиляции с помощью обычного кода, без макросов. Это революционное изменение — сериализация, ORM, логирование смогут быть написаны на чистом C++ без кодогенерации.

Contracts — ещё одна ожидаемая фича: precondition, postcondition, assertion прямо в синтаксисе языка. Документация и проверка в одном месте, опционально проверяемая в runtime.

✏️ Какую фичу из планируемых в C++26 вы ждёте больше всего? И есть ли что-то, чего в языке, на ваш взгляд, всё ещё не хватает?


📍Навигация: Вакансии • Задачи • Собесы

Библиотека C/C++ разработчика

#междусобойчик

🍬 Closure size и SBO: когда лямбда уходит в куч

Размер объекта-замыкания напрямую влияет на то, выделяется ли память в куче при хранении в std::function. Понимание Small Buffer Optimization критично для low-latency кода.

⚡️ std::function содержит внутренний буфер (обычно 16–32 байта в зависимости от реализации). Если closure влезает — heap allocation не происходит:

// sizeof closure = sizeof(int) = 4 байта → SBO
auto f1 = [x = 42]() { return x; };
std::function<int()> sf1 = f1;  // нет heap allocation

// sizeof closure = 3 * sizeof(string) → возможно > SBO
std::string s1, s2, s3;
auto f2 = [s1, s2, s3]() { return s1 + s2 + s3; };
std::function<int()> sf2 = f2;  // возможно heap allocation

🔍 Практическое правило: захватываешь больше 3-х примитивных значений — жди heap allocation. std::string, вектор, любой объект с указателем внутри — почти гарантия.

⚠️ Решения для latency-sensitive кода:

• std::move_only_function (C++23) — меньше overhead, нет копирования
• Ручной std::aligned_storage + placement new

❗️ SBO — деталь реализации стандартной библиотеки, не гарантированная стандартом. Для критичного кода измеряй, не предполагай. Конкретный порог зависит от libstdc++/libc++/MSVC STL.

📍Навигация: Вакансии • Задачи • Собесы

Библиотека C/C++ разработчика

#под_капотом

🍿 Почему локальные переменные «бесплатны» — и что на самом деле происходит при их создании?

Большинство разработчиков знают, что локальные переменные живут на стеке. Но мало кто задумывается: что значит «выделить память на стеке»? Спойлер — никакого malloc там нет.

🔍 Механизм

Стек — это непрерывный блок памяти, закреплённый за потоком при его запуске (обычно 1–8 МБ). Управление им сводится к одному регистру — rsp (stack pointer). При входе в функцию компилятор заранее вычисляет суммарный размер всех локальных переменных и генерирует одну инструкцию:

sub rsp, 48   ; "выделить" место под все локалы сразу
              ; 48 - смещение в байтах, на которое 
              ; нужно сдвинуть указатель, чтобы 
              ; выделить память под переменные 

Никакого поиска свободного блока. Никакого обращения к ОС. Одна арифметическая операция над регистром.


⚡️ При выходе из функции

add rsp, 48   ; "освободить" — снова одна инструкция

Данные никуда не деваются физически — они просто становятся «за пределами» стека. Следующий вызов функции затрёт их своими данными.


❗️ Почему это важно

Аллокация на стеке — это O(1) по времени и нулевые накладные расходы на освобождение. Именно поэтому int x = 5; внутри функции принципиально дешевле new int(5) — разница не в синтаксисе, а в том, какой механизм памяти задействован.

✏️ Если видишь узкое место с частыми мелкими аллокациями — сначала спроси: можно ли это положить на стек?


📍Навигация: Вакансии • Задачи • Собесы

Библиотека C/C++ разработчика

#под_капотом