Библиотека C/C++ разработчика | cpp, boost, qt
19.2K subscribers
2.07K photos
67 videos
16 files
4.38K links
Все самое полезное для плюсовика и сишника в одном канале.

По рекламе: @proglib_adv

Учиться у нас: https://proglib.io/w/d6cd2932

Для обратной связи: @proglibrary_feeedback_bot

РКН: https://gosuslugi.ru/snet/67a5bac324c8ba6dcaa1ad17

#WXSSA
Download Telegram
🍬 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++ разработчика

#под_капотом
Please open Telegram to view this post
VIEW IN TELEGRAM
👍65
👻 std::span в C++26: то, что должно было быть с самого начала

«Почему нельзя просто передать {1, 2, 3} в функцию?!» — знакомое чувство, когда компилятор смотрит на тебя с осуждением за какой-то список чисел.


💡 std::span появился в C++20 и сразу стал удобным инструментом — но с заметными шероховатостями. В C++26 их наконец-то зашлифовали.

Что изменилось:

span<const T> теперь понимает {1, 2, 3} без магии двойных скобок — просто работает
• добавили at() с проверкой границ, как у всех нормальных контейнеров. Да, его не было. Да, это странно
• CTAD стал умнее: если размер известен на этапе компиляции — он и выводится как статический, а не теряется в dynamic_extent

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

👉 Статья

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

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

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

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

🔍 Механизм

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

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


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


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

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


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


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

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

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


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

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

#под_капотом
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5🔥1
Почитали тут свежий отчёт по рынку ИИ-ускорителей в РФ: оказывается, 54% компаний тормозят внедрение ИИ исключительно из-за конских цен на инфраструктуру.

Ну, то есть написать пет-проект с вызовом API это задача на вечер, а вот запустить агента в продакшн так, чтобы он не сжёг бюджет отдела за неделю — суровая инженерия.

По сути, сейчас мало уметь собирать RAG. Нужно считать токены, настраивать time-travel дебаг в LangGraph и уметь роутить запросы на лету. Всё это мы учли в обновлённом курсе по разработке AI-агентов, где акцент сделан именно на AgentOps и жёсткий контроль ресурсов.

Также в программе:

— оценка качества, трейсинг и защита от деградации пайплайнов;
— мультиагентные паттерны и интеграция по протоколу MCP;
— локальный деплой Open Source под 152-ФЗ (когда данные нельзя выносить наружу).

Кажется, это единственный адекватный roadmap по переходу от блокнотов к enterprise-решениям.

Прямо сейчас можно урвать курс с увесистой скидкой (49 000 ₽ 62 990 ₽ за базовый тариф и 99 000 ₽ 124 990 ₽ за продвинутый трек), но стоит поторопиться — на потоке осталось всего 5 мест.

👉 Зафиксировать цену и начать собирать агентов, за которых не стыдно в проде