#cpp

Ещё есть такой коллега у меня Паша Сухов. Ну как коллега. Он в Доставке вообще работает, но ведь это всё ещё Яндекс. Так что коллега.

Пашу вы могли видеть на C++ Russia:
- Полезные трюки С++ на примере организации пайплайна
- Как заставить шаблоны компилироваться быстро и выглядеть опрятно

Ещё с Пашей мы вместе [грубо говоря] делали несколько внешних мероприятий. Не грубо говоря, [в составе небольшой группы из нескольких яндексолег] делали ещё несколько внутренних. Вместе занимаемся плюсовым коммьюнити внутри.

У Паши очень широкий кругозор. Сильнейшие лапищи программиста. Он большой оригинал и довольно креативный дядька. Огромная куча интересных историй и крутейший рабочий опыт и деятельность в целом. Паша неприлично много читает (100-150 книг в год; Паша попросил отметить, что читает он всякую фигню).

Паша поделился ещё некоторыми фактами для внешнего читателя, но я их приберегу на будущее.

И Паша подготовил очень интересный доклад на один из наших внутренних C++ митапов. Доклад, с разрешения автора, привожу вам в текстовом формате. Конечно же, не полностью, т.к., во-первых, не хочется делать объёмный материал, а, во-вторых, хочется оставить некоторую загадку.

Всё близко к тексту с минимальным количеством редакции от Пашиного лица.

Военный синус: когда C++ показывает свой характер.

https://github.com/dasfex/articles/blob/trunk/sin.md

Я решил не юзать больше телеграф. И я понимаю, что возможно вам читать будет чуть неудобнее, но так я хотя бы буду уверен, что контент не потеряется, т.к. уже несколько раз наталкивался на потерянные куски и картинки в постах. + редактор в md более приятный, чем телеграф рандом.

#books #cpp

Вредные советы для C++ программистов. Андрей Карпов. (2023г.)

Книжка строится в следующем формате:
- даётся какой-то вредный совет вида "делайте плохо"
- даётся объяснение, почему совет вредный и как же стоит делать правильно.

Некоторые советы довольно базовые, например не сравнивать double с double через ==, не расширять пространство std просто так или не пользоваться C-style cast. Ничего нового вы здесь скорее всего не найдёте, если уже пару лет на плюсах пописали.

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

Были отдельные места, в которых я не разбираюсь просто потому что не встречался (конкретно про stdafx.h и precompiled headers). За эту часть спасибо.

Общее впечатление: книга довольно базовая. По ощущениям даже скорее маркетинговая, т.к. всё пропитано стилем PVS студии. Возможно для этого она и была задумана.

Тем не менее, автору успехов в будущих литературных движениях. И благодарность за то, что когда-то в 2023м на Highload он мне эту самую книжку вручил.

Вредный совет их трёх.

Залинкую заодно более подробный обзор от Константина Владимирова: https://xn--r1a.website/cpp_lects_rus/288

#cpp

Сегодня небольшой рассказ про недавний баг.

Опять UB моими руками.

https://github.com/dasfex/articles/blob/trunk/one_more_ub.md

#cpp

Время -- деньги.

Стандарт говорит [упрощая], что компиляторы должны поддерживать только наблюдаемое поведение. А как он там это делает, это уже его дело.

Есть несколько уровней оптимизаций.

O0 (о ноль)

База. Компилятор делает минимальный анализ и минимальное кол-во оптимизаций. Сохраняется полная семантика программы. Дефолтный вариант. Идеально для дебага.

O1

Компилятор применяет простые оптимизации без сложного анализа: dead code elimination, constant propagation, basic inlining.
У GCC тут уже 48 оптимизаций.
Используется редко, когда не хочется сильно замедлить компиляцию очень больших программ (друг отметил, что это нужно только маргиналам).

O2

Самый народный уровень.
Множество оптимизаций без speed-space трейдофа: unroll loops, vectorization, strict aliasing.

O3

Включаем максимальный перфоманс отдельной программы. Всё ради скорости. Более агрессивно оптимизируем циклы, больше инлайним, больше векторизируем. Из-за сильной векторизации и инлайнинга бинарник может сильно раздуваться. В том числе поэтому перф может падать, так что на практике не всегда является более оптимальным (при небольшом instruction cache вы станете чаще кешмиссить).
Если увлекаетесь, можно включать при компиляции отдельных файлов, код в которых точно в плюсе. Не задевая всё остальное.

Ofast

Как O3, но включаются опасные оптимизации. Например --ffast-math.
Почему опасные? Потому что скорость получается за счёт точности. Про артефакты можно почитать в Beware of fast-math.

Og (оуджи)

Og = O0 + некоторые оптимизации из O1, не ухудшающие debug experience.

Os

Os = оптимизации из O2, не увеличивающие размер кода + некоторые дополнительные, позволяющие сократить размер исполняемого кода. Трейдофим немного, но в меру.

Oz

Когда у вас мощнейшие ограничения по размеру бинарника и использованию памяти, выбираем Oz. Заодно можно просадить и перф. Но иногда в embedded только так.
Может увеличить кол-во исполняемых инструкций, если их можно закодировать меньшим кол-вом байтов.
Дебагать может быть тоже уже нереально больно. Но как есть.

Мы не говорим про LTO (и ThinLTO) и PGO. Мы не говорим про -march=... и другие. Может когда-нибудь потом..

Доклад в тему: What GCC optimization level is best for you?
В докладе про сами оптимизации и много сравнения с LLVM в разных плоскостях по разным оптимизациям. Может быть полезно, если хотите осознать, какой компилятор лучше под ваши конкретные нужды, т.к. трейдофы выбирают разные.

#cpp

Сегодня Папа C++ в русскоязычном коммьюнити (Антон Полухин) рассказывал про новости комитета стандартизации. В частности C++26.

Контент:

- новая фича (Антон утверждает, что это полезно для метапроги)

Тут Антон показывал, как можно сделать утилитку sequence<N>, чтобы заработал такой пример:

auto [i1, i2, i3] = sequence<3>{}; // 0 1 2

Теперь такое из коробки работает для std::integer_sequence (C++26).

- compile time std::format, что улучшает читаемость ошибок компиляции

- контракты 🤝 hardening (друзья на век)

- рефлексия:
- в рефлексии доступность к приватным членам класса на месте
- consteval block

- баги всякие
- может быть успеют поправить P3725
- ub в <type_traits>: работа с incomplete типами (не оч корректна)
- basic_string::append/assign принимают std::string (потенциально лишние копии)
- uniform_uint_distribution<uint8_t> == ub
- и ещё много других!

И всякие добавляшки.

Живём!

#cpp

System Level Meetup 2025

🌼 Первым докладом был «Корутинные оптимизации в компиляторах» от глыбы Константина Владимирова и коллеги глыбы Юлия Тарасова.

Доклад про корутины концептуально, их реализацию и разные оптимизации по теме (в частности в LLVM). Сложно блин! И поэтому круто. Правда придётся потом пересмотреть ещё пару раз.

🌼 Далее Сергей Чеботарёв рассказывал «Модули С++20 в существующий проект: лёгкая прогулка или прыжок в бездну?».

Сергей рассказывал про попытку начать использовать модули в реальном проекте: какой подход выбрали и какую кучу проблем насобирали по пути. С решениями конечно.

🌼 «LRU-кеш: от решения с собеседования до production-уровня» Ильи Шишкова.
Кеш у Ильи не базовый бэкендерский. Он хранит какие-то артефакты в шареной между различными процессами памяти.
Имхо крутая история про полезность правильного трейдофа. На самом деле иногда нам достаточно приблизительное решение, что позволяет упрощать/экономить. Надо учиться такое подмечать и вовремя использовать.
Код конечно у ребят глаз не радует. Может я привередливый.

Круто #1: в итоге получается не жоское решение, которое разваливает всё-всё, а чуть медленее на большинстве запросов, зато гораздо быстрее на тяжёлом хвосте. Уменьшать дисперсию тоже очень полезно. Это предсказуемость, которой иногда сильно не хватает.

Круто #2: Илья несколько раз говорит, что к чему-то не дошёл в процессе решения задачи.
Важно уметь вовремя остановиться. Мы можем улучшать что-то бесконечно, но если вы начинаете тратить больше, чем в итоге получаете, скажите себе хватит. Это про взрослое отношение к задачам.

🌼 «Когда действительно нужны алгоритмы: опыт оптимизации kd-tree» Саши Голубева.

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

С Сашей мы год вместе занимались С++ community в Яндексе. Вот такой мужик👍

Ещё на C++ Russia 2024 я Сашу вином облил. Не специально.

🌼 Анастасия Черникова рассказывала «Анатомия чекеров в clang-tidy».
Доклад буквально про то, как он называется.
Анастасия рассказывает про разные способы проверять качество кода. Глубже уходит в статический анализ. Рассказывает про AST, разные классы чекеров и сами чекеры из LLVM инфраструктуры.
А дальше рассказывает, как она дорабатывала один из чекеров и как это вообще делается.

🌼 Заканчивал C++ трек доклад «Строки, строки, строки и initializer_list» Антона Полухина.
Антон рассказывал про разные проблемы со строками, их лайфтаймом, std::string_view, кастомную поделку для литералов (чтобы быть уверенными в их времени жизни), а ещё, конечно же, про то, как избегать лишних аллокаций там, где мы можем случайно их словить.

Мне понравилось.

#cpp

Пост небольшой, но с картинками. Даже не пост, а заметка.

Heap pinning: https://github.com/dasfex/articles/blob/trunk/heap_pinning.md

#cpp

Сегодня только один доклад. Зато какой!

Using Floating-point in C++: What Works, What Breaks, and Why. Egor Suvorov.

Егор рассказывает про устройство чисел с плавающей запятой. Миллион возможных проблем с ними в рамках спецификации, корнеров и C++. С примерами, как и что может пойти не так (некоторые примеры на мой взгляд достойны @cpp_durka Паши Сухова).

Я смотрел другие доклады Егора. Они всегда стройне, полные. От начала до конца. Но после этого доклада огромная гора уважения автору (вторая). Это ж сколько информации надо было перелопатить, чтобы прийти и рассказать потом про эту необъёмную яму, в которой закопаться и потеряться в любой случайный момент не составляет никакого труда. Сколько усидчивости и терпения надо иметь, чтобы родить один доклад. Очень красивый и подробный.

Потрясающе.

Один из докладов Егора уже упоминал тут: пункт 3 в t.me/thisnotes/285.

Другой его доклад (lightning) тоже недавно выложили: ⁠Do Not Compare Integers and Floats in C++: Sorting Pitfalls, UB & Type Conversion Explained.
Тут про проблему сортировки целочисленных типов вместе с числами с плавающей запятой.
Может надо как Амазон. Посадить 1000 человек. Пусть на глаз сравнивают. Долго, зато не ошибёмся!
Тема упоминается и в полном докладе, но вдруг вам только это интересно.

Что-то про сложение чисел с плавающей точкой уже упоминалось: t.me/thisnotes/288

Там же в комментах накидывали пачку статей, на которую и Егор, судя по всему, опирался: https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/

И тут под названием «What Every Computer Scientist Should Know About Floating-Point Arithmetic» есть жирная статья (хотя я привык её видеть в виде 100страничной пдфки) про то, что надо знать про floating point numbers: https://floating-point-gui.de/references/
Я долго думал, что когда-нибудь прочитаю, но наверное докладом Егора тему для себя можно закрыть.

Наслаждайтесь.

#cpp

The worst programming language of all time.

Или нет?

Возможно вам уже попадалось видео: youtube.com/watch?v=7fGB-hjc2Gc, рассказывающее, почему C++ — самый ужасный язык программирования. Разберём автором рассказанное.

https://github.com/dasfex/articles/blob/trunk/the_worst_programming_language_of_all_time.md

[Пост появился раньше на пару дней на] Patreon и Boosty.

Спасибо Artyom Garkavy за поддержку.

#books #cpp

C++17 - Iterating Problems.

Я бы сказал, что это не книга, а книжка. Возможно мегабуклет. Просто из-за размера. Но пусть будет книга.

Автор поставил себе задачу исследовать возможности C++17 (да, сегодня это уже немного outdated увлечение).

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

Фичи языка, которые рассматриваются в книге, покрывают (но не ограничиваются): итераторы, type traits, SFINAE, вычисления на компиляции, fold expressions, std::variant, std::any.

Понятно, что код в итоге смотрится ужасно. Вот, например, для Hello world:

template <typename I, typename O>
auto
hello_world(I first, I last, O out) {
    return std::copy(first, last, out);
}

int
main(int, char *[]) {
    auto hello = std::array{"Hello", "World!"};
    auto out = os_iterator<std::string>{std::cout, ", "};
    hello_world(hello.begin(), hello.end(), out);
    return 0;
}

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

Причём это самая простая задача. С самым сжатым кодом. Дальше начинается полный разнос с нечитаемыми решениями.

Но!

Книга может научить важным вещам, которые вам понадобятся при проектировании общих решений/алгоритмов. Подобные задачи всегда связаны с большим количеством крайних случаев и потенциальных ошибок. Автор хоть и не получает всегда идеальное решение (так как задача — поюзать как можно больше фичей), но причины тех или иных решений объясняет. Возможно, не все из них имеют отношение к реальным задачам. Но важно уловить паттерн и ход мысли.

Из минусов: с какого-то момента книга становится монотонной. Ну штош.

3 итератора из 7.

Спасибо Artyom Garkavy и niki4smirn.
Patreon, Boosty.

#cpp

Принёс доклады с C++ Russia 2025.

В хронологическом порядке.

0. LLVM MemProf и методы профилирования памяти.
Алексей Веселовский.

Крутой доклад про профилирование памяти. Что важно, осознаваемый на 1.5х без напряга, но при этом всё ещё сложноватый.

1. [Не]очевидные оптимизации и паттерны из userver. Антон Полухин.

Антон продолжал серию докладов про всякие приколюхи из userver.
Обычно (и в этот раз, и, я уверен, в в конференции этого года) это рассказ про несколько отдельных улучшений/фиксов/оптимизаций из userver. Глубоко в теорию в них не закапываемся. Скорее подразумевается наличие экспертизы.
Интересно как точка расширения сознания, чтобы потом пойти чего-то ещё поизучать.

На youtube есть смешной комментарий:
> ты ему слово, а он тебе трюки из userver

2. Как компиляторы на основе LLVM моделируют неопределенное поведение и извлекают из него пользу. Макс Казанцев.

Доклад про некоторую внутрянку работы с UB в компиляторах, как они детектят проблемные случаи и что делают с этой информацией. Имхо довольно свежо.

3. Замеряем производительность для высоконагруженных проектов с Google Benchmark. Савва Лебедев.

Введение в gbench. Что важно, там и базовое что-то есть, и что-то, что может вам пригодиться, если вы вроде какие-то бенчмарки писали, но в перф глубоко не погружены. Для становления perf-person.

4. Уроки кодогенерации JSON Schema. Василий Куликов.

Вася — один из основных контрибьюторов userver.
Снаружи (вне Яндекса), в отличие от опенсорсной версии фреймворка, userver изначально имел кодген, который по OpenAPI спецификации позволял генерить готовый код для ручек, внутренних классов и работы с ними. Не нужно было раскладывать JSON в плюсовую структуру самому, например.

Вася рассказывал про новую кодогенерацию в фреймворке.

Я так понимаю, что в итоге именно она в опенсорсе и появилась.

5. Как мы работаем над производительностью мобильного приложения в 2ГИС. Дмитрий Ястребков.

Рассказ скорее фановый, про процессы, похвалиться. Скорее для хайлоада имхо.
Но круто, что чуваки болеют за перф и системно что-то с ним делают. К сожалению, это не везде так. И к сожалению, иногда это напрямую задевает пользователей.

Когда я на конфе слушал доклад, меня что-то там смутило. Что-то связанное с измерением метрик или интерпретацией данных.
За год я забыл, к сожалению.

6. Лицензии ПО: теория, которая спасает от финансовых катастроф. Ольга Кузмичева, Георгий Панюшкин.

Ребята рассказывали про то, что и заявлено в заголовке.

Я в теме нуб. Было интересно послушать про что-то важное для сферы в целом, но какое-то тёмное непонятное юридическое.

7. Ржавеющие плюсы: как внедрять современные проверки С++ в промышленных масштабах. Винсент Амбо.

Винсент рассказывал про харденинг и его внедрение в Яндексе.

Плюсы и безопасность это топики тяжёлые (если вместе обсуждать), так что всегда полезно ещё что-то сделать в этом месте.

8. Как заставить шаблоны компилироваться быстро и выглядеть опрятно. Павел Сухов.

Пашу вы должны уже знать.
Меня тоже (я рядом стоял).

Паша рассказывает про проблемы компиляции шаблонов, про перф этого всего дела, и про то, как выглядеть опрятно (это отдельный вопрос).

9. [не доклад, а болталка] Чему C++ может научиться? Антон Полухин. Павел Новиков.

Люблю послушать некоторую внутрянку комитета по стандартизации. Тут Антон как раз рассказал пару небольших историй. Зашло.
.

Я выступал на offline only активности с лайтнингом. Рассказывал про оптимизацию разработки. Это была вариация этого доклада с некоторым уходом в сторону плюсов.

#cpp

Поток (англ. flux)

https://github.com/dasfex/articles/blob/trunk/flux.md

Как обычно, на том же Patreon или Boosty пост был доступен раньше.

Спасибо Artyom Garkavy и niki4smirn.

#cpp

Day 1.

#include

Думаю, все вы знаете, что #include просто вставляет весь код в файл, в котором он расположен. Из-за этого даже простой Hello world с использованием std::cout разрастается до десятков-сотен тысяч строк (хотя сам хедер может быть маленький, он транзитивно тянет много других зависимостей). Собсна поэтому инклуды не очень любят: легко засрать ваш проект и получить большое время компиляции. Отсюда и появляются штуки вроде forward declaration, pimpl, precompiled headers, include-what-you-use и модули.

Инклудить вы можете что угодно. Хоть txt, хоть бинарный файл. Препроцессору на это всё равно. Главное, чтобы содержимое после препроцессинга было валидно.

Можно хоть так:

#include "/dev/stdin"

и потом

echo 'int x = 42;' | g++ main.cpp

Порядок инклудов может значимо менять поведение в программе. Вот вам пример от Паши: https://xn--r1a.website/cpp_durka/49

Инклуды могут быть с <> и с "". Вариант подключения влияет на то, где хедеры ищутся.

Когда-то препроцессор не умел добавлять пустую строку после инклудов, потому обязательно было иметь пустую строку в конце вашего файла. Сейчас можно и без этого, но душе уже не прикажешь...

Ну и всегда можно воспользоваться инструментом неправильно. Случайно или специально. Вспомним The Grand C++ Error Explosion Competition.

@thisnotes. Patreon, Boosty.
Спасибо Artyom Garkavy и niki4smirn.

#cpp

Day 2.

Так как #include просто вставляет код файла, приходится учитывать возможности, что один и тот же хедер притянется несколько раз. А это приводит к повторному объявлению ваших классов, функций, переменных и всего остального.

Защищаться от подобной ситуации нам помогают include guards (и pragma, но про неё не сегодня). Пишем в начале файла

#ifndef GUARD_H
#define GUARD_H

#endif // GUARD_H

Какие могут быть проблемы?

Если один и тот же GUARD используется в нескольких файлах, то один из них просто молча не подключится. Удачи дебагать!
Сейчас IDE (по крайней мере те, с которыми я работал) успешно генерируют длинное название, связанное с именем файла. Но не всегда успешно меняют имена guards при переименовании файла.

Есть ещё мнение, что include guards медленные. Хотя обычно, если у вас вид канонический, как в примере выше, то компиляторы способны запомнить, что файл уже был прочитан, и не тратить время на повторные операции.
Но если у вас какой-то специфический случай (начинаете вставлять код до include guards или после), то уже уверенными быть не стоит.

Исходя из того, как работают макросы и на что опираются guards, получается, что легко можно сломать инклуд хедера, если где-то определить #define:

#define GUARD_H
#include "some.h"

Вот ещё один пример, когда порядок хедеров может на что-то влиять.

@thisnotes. Patreon, Boosty.
Спасибо Artyom Garkavy и niki4smirn.

#cpp

Day 3.

Другой способ быть уверенным, что хедер включится только единожды: #pragma once.

Важно помнить, что это не стандартное решение, а универсальное расширение, которое реализуется де-факто всеми компиляторами.

#pragma once хорошо оптимизируется (фактически). С ней даже чуть проще, так как она просто влияет на файл, в котором находится, когда include guards только на то, что внутри своего скоупа.

#pragma once обычно работает через какой-то признак, помогающий понять, что файл — один и тот же. Из вариантов могут быть:
• inode
• канонический path
• какой-то hash
• и другие варианты.

Из-за чего в сложных специфических системах может вполне себе сломаться. И вы получите один и тот же файл дважды. Удачи дебагать!

Аналогично могут быть проблемы в распределённых build-системах.

Иногда вы хотите, чтобы один файл инклудился дважды. Тогда #pragma once вам не подходит.

В некоторых сферах #include guards выбирают просто за надёжность и стабильность, так как они зависят исключительно от кода, а не ещё каких-то посторонних вещей.

Можно вообще в один файл совать и #pragma once, и include guards. Чтобы спокойнее было.

@thisnotes. Patreon, Boosty.
Спасибо Artyom Garkavy и niki4smirn.

#cpp

Day 4.

Макросы просто подменяют текст. Вот прям втупую. Но мы часто про это забываем, потому часто пишем их неправильно.

Паша @cppdurka Сухов говорил, что когда-то видел какой-то гайд на 18 страниц, как правильно писать макросы. Видел и потерял. А теперь жалеет об этом.

Я бы тоже хотел почитать. Скиньте, если знаете про такой!

@thisnotes. Patreon, Boosty.
Спасибо Artyom Garkavy и niki4smirn.

#cpp

Day 5.

#ifndef в include guards на самом деле #if !defined(...). Есть ещё #ifdef (#if defined(...)). Сам #if тоже есть. Можете намутить себе условной компиляции по самые колени. Например, может у вас есть какая-то дебажная сборка с большим кол-вом логов:

#ifdef DEBUG
  printf("debug log");
#endif

И код можно скомпилировать с -DDEBUG.

Или вы хотите написать разную логику для 32-битной и 64-битных систем:

#if !(defined __LP64__ || defined __LLP64__) || defined _WIN32 && !defined _WIN64
 // code for a 32-bit system
#else
 // code for a 64-bit system
#endif

Или вы хотите использовать новый стандарт, если он доступен, и не использовать, если есть своя поделка:

#if __cplusplus >= 202002L
    #include <span>
#else
    #include "my_span.hpp"
#endif

Хотя правильнее было бы проверять не на стандарт, а на доступность фичи/инклуда/атрибута, так как стандарт может быть новым, а STL старой. А некоторые фичи могут бекпортить.

#if __cpp_lib_span

#if __has_include(<format>)

#if __has_cpp_attribute(likely)
    #define LIKELY [[likely]]
#else
    #define LIKELY
#endif

Значения __cpp_* макросов это кстати дата принятия фичи WG21. Например, для __cpp_constexpr это 202211L (ноябрь 2022). Для того же constexpr можно узнавать его версию и соответственно набор возможностей, которые вы можете использовать, так как от стандарта к стандарту он сильно умощнялся.

Кто-то мне рассказывал байку, что MSVC много лет врал про значение __cplusplus (всегда возвращал 199711L, даже для C++17), потому писали вот так:

#if defined(_MSVC_LANG)
    #define CPP_VER _MSVC_LANG
#else
    #define CPP_VER __cplusplus
#endif

@thisnotes. Patreon, Boosty.
Спасибо Artyom Garkavy и niki4smirn.

#cpp

Day 6.

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

#define SQR(x) x * x

В зависимости от способа использования, вы можете не получить или получить проблемы. В таком коде:

int a = SQR(1 + 2);

мы на самом деле получим

int a = 1 + 2 * 1 + 2;

Что не совсем то, что вы ожидали.

Для надёжности лучше завернуть аргументы в скобки:

#define SQR(x) (x) * (x)

Но этого тоже может иногда не хватать:

#define INC(x) (x) + 1

int a = 10 / INC(1 + 1);

Получим:

int a = 10 / (1 + 1) + 1;

Что тоже не то, что мы ожидали. Так что адекватный макрос должен как минимум завернуть в скобки каждый отдельный аргумент + завернуть всё выражение:

#define SQR(x) ((x) * (x))

Как максимум, ваш x может быть вообще-то функцией с сайд-эффектом:

int x = SQR(GetValueFromDbAndPostToKafka());

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

Мб пора начать сворачивать с макродорожки на что-то более современное......

@thisnotes. Patreon, Boosty.
Спасибо Artyom Garkavy и niki4smirn.

#cpp

Day 7.

Вчера мы писали макросы, которые заменяли собой один statement. А что, если я хочу что-то более сложное?

Обопрусь на пример от Паши (https://xn--r1a.website/cpp_durka/23): напишем макрос для инкремента двух переменных.

#define INCREMENT_BOTH(x, y) (x)++; (y)++ 

Тут мы умные. Сразу взяли выражения в скобки. Не поставили в конце ; , чтобы обязать пользователя её поставить самому (для консистентности кода).

Но если мы чуть-чуть отступим от глупого использования:

if (condition)
    INCREMENT_BOTH(a, b);

мы получим

if (condition)
    (a)++; (b)++;

b инкрементится вне зависимости от условия.

Или ещё пример:

#define MACRO(condition, x) if (condition) std::cout << (x)

if (flag)
  MACRO(flag2, 5);
else
  std::cout << 10;

Тут else вдруг начинает относиться к if из макроса, а не изначальному, что очевидно баг.

Канонический способ такое исправить:

#define INCREMENT_BOTH(x, y) \
    do {                     \
        (x)++;               \
        (y)++;               \
    } while (0)

#define MACRO(condition, x)  \
    do {                     \
        if (condition) {     \
            std::cout << (x);\
        }                    \
    } while (0)

@thisnotes. Patreon, Boosty.
Спасибо Artyom Garkavy и niki4smirn.

#cpp

Day 8.

В C тоже есть массивы. И работягам тоже хочется знать, сколько в этих массивах элементов. Стандартного решения у ребят там нет, но есть общий подход, перетекающий из кодовой базы в кодовую базу. Зовётся ARRAY_LENGTH/ARRAY_LEN/ARRAY_SIZE/COUNTOF/...
Выглядит так:

#define ARRAY_LENGTH(x) (sizeof(x) / sizeof((x)[0]))

Тут мы полагаемся на sizeof, который, согласно стандарту C99 (моя вольная интерпретация):

sizeof возвращает размер операнда (в байтах). Размер зависит от типа операнда. Результат — int. Обычно результат не evaluated и является integer constant.

Another use of the sizeof operator is to compute the number of elements in an array:

sizeof array / sizeof array[0]

Так что sizeof(x) вернёт кол-во байт типа массива (если x — массив int[3], то можем получить (в зависимости от системы) 12). sizeof((x)[0]) вернёт размер типа одного элемента (в нашем случае 4). Вот и получаем 3.

На собесах могут спрашивать вопросы с подвохом вида:

int x = 10;
sizeof(x++);
std::cout << x; // result?

Конечно, вы на такое не попадётесь и скажете 10, ведь sizeof интересует тип. Он не evaluatит свой аргумент. Но всегда ли это так?

Конечно нет!
Если ваш аргумент — Variable Length Array, то sizeof придётся вычислить аргумент. Мы можем запруфать это через наличие сайдэффекта:

int f() {
    printf("called\n");
    return 10;
}

int main() {
    sizeof(int[f()]);
}

Увидим called в output. https://godbolt.org/z/8G1soa8T1

Теперь срочно требуйте оффер х3 от вашего текущего дохода, ведь собеседующий почти наверняка этого не знает.

@thisnotes. Patreon, Boosty.
Спасибо Artyom Garkavy и niki4smirn.