this->notes.

#cpp Day 4. Макросы просто подменяют текст. Вот прям втупую. Но мы часто про это забываем, потому часто пишем их неправильно. Паша @cppdurka Сухов говорил, что когда-то видел какой-то гайд на 18 страниц, как правильно писать макросы. Видел и потерял. А теперь жалеет об этом. Я бы тоже хотел почитать. Скиньте, если знаете про такой! @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 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 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://t.me/cpp_durka/49 Инклуды могут быть с <> и с "". Вариант подключения влияет на то, где хедеры ищутся. Когда-то препроцессор не умел добавлять пустую строку после инклудов, потому обязательно было иметь пустую строку в конце вашего файла. Сейчас можно и без этого, но душе уже не прикажешь... Ну и всегда можно воспользоваться инструментом неправильно. Случайно или специально. Вспомним The Grand C++ Error Explosion Competition. @thisnotes. Patreon, Boosty. Спасибо Artyom Garkavy и niki4smirn.

1 июня начнём марафон. Все посты будут объединены одной темой (которую вы быстро поймёте, я думаю). Появляться будут должны в районе 9 утра по Лондону (11 по Минску/Москве). Постараюсь делать микропост каждый день. Хочется, чтобы он охватывался за минуту-две и давал вам маленький кусочек знания. А может и ничего не давал. Кто знает! Возможно будем прерываться на другие посты. Но это только если важно будет запостить в конкретное время, чтобы актуальность не терялась. Как долго марафон продлится, выясним в процессе. Я таким раньше не занимался. Будем открывать новое коллективно.

#list 0. [playlist] Advent of Compiler Optimisations 2025. Matt Godbolt. Если вы, как и я, пропустили, что Matt Godbolt (мистер компайлер эксплорер) в декабре выпустил advent оптимизаций в компиляторах, давайте закрывать этот пробел. Плейлист состоит из 24 видео по 5-10 минут про разные оптимизации компиляторов. Некоторые более базовые и широкоизвестные, некоторые не прям. Очень понравилось. Дядя поясняет всё-всё. Между делом показывает разные фичи godbolt. В конце есть замечательное видео с так называемыми bloopers. 1. [talk] Exceptions in C++: Better Design Through Analysis of Real World Usage. Peter Muldoon. Доклад про исключения. Конкретно мне нравится часть про антипаттерны при использовании инструмента, почему они антипаттерны, как исправляться. Хорошее пособие про то, как надо. 2. [article] Using an engineering notebook. Я прочитал эту статью ещё в феврале. Пару дней сидел думал. Потом начал вести блокнотик по рабочим делам. Основной профит, который я начал получать: голова сильно разгружается. Я выписываю какие-то вещи, которые сделал (даже если это что-то простое). Даже если по мелочи поревьюил какой-то PR. Отмечание таких вещей помогает чувствовать хоть какой-то прогресс, когда он фактически в результатах дня может отсутствовать. Ещё я записываю вещи, которые надо/можно сделать. Возможно сделать после встречи, а возможно когда-нибудь через год, если руки дойдут. Главное, что все они в одном месте. Стараюсь не оставлять пустые дни. Просто чтобы держать привычку. Не может быть такого, чтобы за день ничего не было записать. Совсем недавно начал делать аналогично и для нерабочей части жизни. И, кажется, начинаю в целом записывать больше вещей и меньше про них думать. Очень советую вам попробовать. 3. [article] The gold standard of optimization: A look under the hood of RollerCoaster Tycoon. Мне особенно понравилась часть Game Design for Performance. Продуктовые решения неимоверно влияют на реализацию. И очень круто, когда можно найти какой-то красивый компромисс. Наша задача как программистов, технической стороны, научиться такие красивые компромиссы находить и пояснять, почему они действительно имеют смысл. Patreon, Boosty.

#common Вылил текста про проблемы роста и полезность индивидуального плана развития. https://github.com/dasfex/articles/blob/trunk/ipr.md Patreon, Boosty. Спасибо Artyom Garkavy и niki4smirn.

#list 0. [talk] CTRACK: C++ Performance Tracking and Bottleneck Discovery. Grischa Hauser. Автор рассказывает про новую тулу для измерения перфа ваших программ (догадались, как называется?). Выглядит прикольно. По крайней мере с точки зрения получаемой информации и без опыта использования. Правда мне не очень нравятся инструменты и подходы в целом, ради которых надо менять код. Нахожу регулярно, что таким неудобно пользоваться. 1. [article] Email is crazy. Такой поверхностный, слегка научпоповский пост про то, как устроены emails. С вайбом костыль на костыле. 2. [lightning talk] Catching Performance Issues at Compile Time. Keith Stockdale. 3. [lol] WTF-8 encoding are real. 4. [fact] В последнее время активно пользовался valgrind --tool=massif и надо было анализировать результаты. Есть 2 рекомендуемых способа: • утилита ms_print, которая печатает ваш massif.out файл в почти таком же формате. Это никак не помогает вам понять, где аллоцируете память. • GUI massif-visualizer, которая запускается со скрипом, не кликается, не отзывается ни на что и ничего полезного не говорит. Зато закинуть выхлоп в агента с доступом к анализируемому коду помогло неимоверно. Потыкал мне в конкретные места, которые кушают слишком много. Попредлагал фиксы. Возможно часть тулинга нам больше не нужна. Patreon или Boosty.

#cpp Поток (англ. flux) https://github.com/dasfex/articles/blob/trunk/flux.md Как обычно, на том же Patreon или Boosty пост был доступен раньше. Спасибо Artyom Garkavy и niki4smirn.

#common Уже фактически начался сезон конференций. Как частый участник и иногда спикер, я (пусть и всего за пару лет) насмотрелся кеков. Потому напомню вам базовые правила. Для участников: • не пытайтесь посетить ВСЁ. Досмóтрите дома в онлайне. Лучше пару докладов качественно, чем всё и быть пиявкой к концу дня. А ещё почитайте абстракты докладов. Почему-то этого почти никогда не делают. • вы идёте не только ради контента, но и нетворка. Не тусуйтесь исключительно со своими коллегами. Познакомьтесь с вот этими тремя рандомными персонами. Опциально бахните с ними пива. Подойдите к тому самому крутому спикеру. Почти наверняка он(а) приятный человек. Если стесняетесь, подумайте заранее, как в 3 предложения себя представить. Вы вообще-то тоже интересные! • будьте уважительны к спикерам. Человек уже вышел на сцену (а вы, почти наверняка, нет) и скорее всего испытывает некоторый объём волнения. Не надо на весь зал и под запись показывать, насколько вы умнее докладчика. Выскажите ему лично. Я был на одном мероприятии на ≈200 человек, где дядька сказал докладчикам в микрофон что-то вроде "идите сначала доучитесь в школе, а потом приходите на конференции выступать". Задайте вопрос, если он действительно есть. Сделайте хорошее дополнение, чтобы поделиться знаниями. • тайм-менеджмент тут тоже важен. Подумайте заранее, когда и куда вы пойдёте. Соображать в короткий перерыв в толпе не очень эффективно. Не забудьте взять воды. • покайфуйте в конце концов. Для спикеров (ну вдруг) (я не хочу рассказывать вам, как делать доклад, как-нибудь потом): • будьте честными со слушателями. Любое лукавство сразу видно. Несколько раз видел, когда докладчики отрицали использование разных источников, типа «сами придумали», а код символ в символ одинаковый. Ради бога, не рассказывайте то, в чём не разбираетесь. Это тоже чувствуется на раз-два. • принимайте фидбек. Если вам кто-то говорит, что тут наверное такая ошибка, поблагодарите и разберитесь потом. Если кто-то говорит, что слайды сложные, значит наверное так оно и есть. • не будьте высокомерными. Есть разные докладчики, которые за слово не по стандарту смерят вас пронзительным взглядом и скажут «тьфу» (особенно актуально для плюсового коммьюнити). Ваше присутствие на сцене не означает, что вы лучше других. • в любом случае вы молодцы. Выйти на толпу это крута.

#common Thoughts on finishing things. Можно почитать на Patreon или github. Как обычно, на том же Patreon или Boosty пост был доступен раньше. Спасибо Artyom Garkavy и niki4smirn.

#highload Redis license stuff. https://github.com/dasfex/articles/blob/trunk/redis_license_stuff.md Спасибо 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 активности с лайтнингом. Рассказывал про оптимизацию разработки. Это была вариация этого доклада с некоторым уходом в сторону плюсов.

#list 0. [talk] "Just switch the compiler", they said. Arne Mertz. Arne Mertz рассказывает, насколько на самом деле сложно переходить на другой компилятор. Проблемы примерно вида: • не компилится • тулчейн не работает • библиотеки не поддерживаются • рантайм ломается С примерами разных проблем. Делится знанием, как пострадать от процесса минимально. Вроде конечно понятно всё, но я как-то раньше не задумывался. 1. [quiz] John Regehr's Integers in C quiz. И это только про С! Хех! Не справился с двумя вопросами (на самом деле с тремя, но там не считается, вы поймёте). Расскажите про ваши успехи в комментариях! 2. [article] the hidden compile-time cost of C++26 reflection. Vittorio Romeo рассказывает про [предварительные] замеры скорости компиляции разного кода с рефлексией. Статья называется как-то с намёком на то, что всё плохо, но вроде сам говорит, что не прям. 3. [article] Code is run more than read. 4. В одной из статей (которой делиться я не буду, так как у меня к ней много вопросов) я увидел вот такую фразу:

we needed a tool that fit our engineering culture

Я надеюсь, у вас тоже возникло ощущение беспросветного булшита. Patreon, Boosty.

#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.

Доброе понедельничное утро. Два прошлых года я выступал на C++ Zero Cost Conf. Eсли вас тут не было, то в 2024 я рассказывал про NRVO, а в прошлом году всякие приколы про шаблоны и математику.

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

Конференция никуда не девается и в этом году: 1 августа можно провести в компании коллег по цеху, особенно если вы в Москве или Белграде. Моя роль от потенциального докладчика сместилась в сторону члена программного комитета. И мы принимаем доклады! У вас есть возможность податься до 11 мая. Детали тут: https://cppzerocostconf.yandex.ru/ Вот картиночка. Не зря ж её кто-то рисовал.

Доброе апреля. 1. Коллега точно подметил, что -Wall это wall of text. 2. Помните, я писал про книгу про API от Сергея Константинова? У Сергея ещё книга про пиво есть. Мне недавно метко подсказали, что API + пиво = IPA Не знаю, как вам это поможет, но в этом что-то есть. 3. Если пропустили контент, то у Miyagi & Эндшпиль вышел трек про std::vector. Так и называется — Vector.

#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 за поддержку.

🤔🤔🤔🤔🤔 Добрый день. Во-первых, хочется выходить в мир. А делать это с чужим лицом на аватарке как-то нехорошо. Я знаю пару кейсов, когда читатели канала думали, что на аватарке автор. Во-вторых количество сил, которое я трачу на канал, растёт всё больше и больше. Это может не видно со стороны, но рано или поздно начнут появляться важные (для меня) и интересные (для вас) материалы. За прошлый год канал стал вдвое больше. Ко мне всё чаще приходят с предложениями запостить рекламу самого разного рода. От офферов за выходные в больших и маленьких компаниях до каких-то абсолютно ботослоповых каналов в тг. За это конечно предлагают деньги. Рекламу непонятно чего я не очень люблю. Особенно не люблю рекламу за деньги, а не за личную симпатию к делу автора или продукта. А вот деньги я люблю. Верю, что ответственность перед читателями поможет мне быть чуть более продуктивным, внимательным, интересующимся. Попробовать что-то новое. И купить жене чуть больше ювелирных изделий. Patreon: https://www.patreon.com/cw/thisnotes/membership Boosty: https://boosty.to/thisnotes Минимальный тир даёт ранний (на 1 день) доступ к постам и статьям. Следующие дадут возможность читать недоступное снаружи, оставить след в канале своим ником или оригинальной идеей для контента. Если вас будет много, будем расширять возможности и количество тиров. Реклама в канале появится только в одном из двух случаев: • я не придумал, где ещё взять денег, а мне нужно срочно хоть сколько-то • мне предложили неприлично много.

#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/ Я долго думал, что когда-нибудь прочитаю, но наверное докладом Егора тему для себя можно закрыть. Наслаждайтесь.