#list

0. [talk] Challenges and Benefits of Upgrading Sea of Thieves From C++14 to C++20.

Ещё одна история про стоимость поддержки больших проектов: как Sea of Thieves переезжали на 2 стандарта вперёд. Довольно жирных.
Внутри конкретные кейсы и проблемы и заодно общие рассуждения про то, насколько нереально делать подобные шаги.

1. [article] Building a web search engine from scratch in two months with 3 billion neural embeddings.

Автор рассказывает про то, как он сделал поисковый движок с нуля. Мотивация: раскачаться + сделать себе норм поиск, который будет выдавать действительно релевантные результаты, а не SEO-optimized контент, и будет отвечать на семантические вопросы, а не просто заниматься keyword матчингом. Типа perplexity на минималках.
Покрывает следующие темы:
- нормализация данных (честно парсит интернет)
- chunking текста, т.к. моделька не может кушать большими кусками (она же не Робин Бобин Барабек)
- crawler
- построение общего пайплайна движка
- хранение всего этого дела
- про решение задачи discovery своих сервисов, и в целом тут чуть больше про стековые/девопс проблемы
- GPU
- шардирование HNSW (не путать с NSFW)
- оптимизацию латенси
- ещё несколько бизнесовых фичей, которые автору просто захотелось
- рассуждения про качество поиска
- 💵💵💵бабки💵💵💵
- заключение.

Текст жирный. Интересный. Местами сложный. Кайфуйте.

2. [article] Expression Templates in C++.

Автор рассказывает про expression templates: где применяются, пишет простую версию для вычисления выражения вида a * b + c и применяет этот механизм для реализации chained comparisons в C++.
Приключение на 20 минут. Не очень сложное, но и не базовичковое. Приятный хороший технический текст.

3. [article] Succinct data structures.

Автор делится своим открытием сжатых структур данных. В статье описание базовых структур, операций и некоторая интуиция, как это работает. Есть ещё и примеры использования.

4. [post] Про время.

Писал про восприятие времени, високосные секунды, виды часов и C++.

===================================

Знаю, что вы у меня не только плюсами едины.

1 ноября в Москве будет Я.Субботник по Go. В программе про userspace networking, сборку мусора в Go 1.25, KV-хранилища, трейсы и афтерпати для присутствующих.

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

Регистрация тут.

===================================

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

#cpp

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

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

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

#common

Я провёл >100 собеседований. Нанял несколько человек. И что-то понял.

Правда только для конкретной команды. Приду я в новое место, мой опыт не обобщится полностью. Сначала хорошо бы прощупать, что в команде нужнее. Какие навыки.

В текущей команде нам жизненно необходимы люди, которые умеют в коммуникацию. У нас очень много разговоров, взаимодействия с разными смежниками, в т.ч. нетехническими. Важно не просто общаться кодом на плюсах, а ещё и доносить мысли простым языком, уметь выяснять требования, даже когда заказчик сам ещё не до конца понял. Донести проблемы и возможности так, чтобы их понял непогруженный человек.

Вы можете быть бесконечно крутым IC, но если вы хотите сидеть в углу и разговаривать только с руководителем раз в неделю на 1х1, то это не к нам. Ну вот так.

При этом всем хочется иметь адекватных коллег. Адекватность проверяется в первую очередь общением. Когда к тебе приходит приятный(-ая) кандидат(ка) и шутки шутит между решением задачек, это круто. У нас вся команда такая. Мы цитаты из Реальных пацанов на дейликах вспоминаем на скорость. Если все такие и ты такой(ая), будет проще работать. Личные отношения укрепляются. Это позитивно сказывается на качестве работы (вовремя узнаёшь новости, инсайты, чаще обсуждаешь мысли -> быстрее принимаешь решения и делаешь проекты, не упускаешь происходящее).

Важны и харды, конечно же. Они не важнее совместимости с командой, но всё же задачи надо делать.

Есть отличные статьи про процесс собеседований в бигтехи. НА МОЙ ЛИЧНЫЙ ВЗГЛЯД это незрелая точка зрения. Не подкреплённая фактами. Которая разбивается на раз-два в момент, когда внутри ты начинаешь вникать, как и что работает на самом деле. Просто людям нравится толпой кричать, какие большие компании плохие. Такой у них рок.

Я выскажу непопулярное мнение, но такие форматы собеседований не есть плохо.

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

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

Сейчас формат поменялся. Коллеги уверенно двигаются в сторону устаканивания процесса. Чтобы пройти один раз разносторонние собесы и потом искать себе команду среди всех сервисов компании. Чтобы задачи и вопросы на собеседованиях были больше про опыт. Подобные новости радуют. Хочется верить, что эволюция процесса продолжится, и станет ещё приятнее.
Олег в статье рассказывает не только про изменения, но и много про проблемы, которые ребята пытались и пытаются починить. Возможно те, которые волновали именно вас, уже в процессе искоренения.

Да, собеседование в Яндекс уже звучит как мем. Но я искренне надеюсь, что через годы восприятие изменится.

Самое важное правило, которое я вынес для себя при найме: есть только два ответа: "hell yeah" или "no".

Брать человека только потому что "ну он(а) вроде норм", а мы уже как-то долго ищем кандидата, не надо. Брать надо только когда ты прям хочешь этого конкретного человека в команду.

Когда я отступал от правила, я ошибался (не все мои наймы были удачными). Но все, где я слышал вот это hell yeah внутри, были настолько успешными, что я немножко даже горжусь каждым из нанятых ребят. Настолько они крутые.

Больше отступать не буду.

#list

0. [talk] Video Game Hacking using Kotlin/Native.

Не самый профильный для канала доклад, но не менее от этого интересный. Докладчик рассказывает про то, как хакал GTA San Andreas с помощью Kotlin. Жоской специфики Kotlin'а там нет, а выглядит это всё замечательно. Нравица.

1. [article] did u ever read so hard u accidentally wrote?

Интересное расследование про то, что чтения в postgres что-то иногда да пишут. Очень круто, глубоко и непонятно.

2. [article] Hidden Messages in Emojis and Hacking the US Treasury.

В декабре прошлого года был инцидент в казначействе трампосударства. Чувак рассказывает, как базовичковая (или нет?) SQL инъекция сделала своё дело.

3. [article] Some of My Favorite Things – Postgres Queries.

Автор делится набором запросов для Postgres (некоторые предпочитают слово "рецептов" в более широком смысле, но мне оно не нравится), которыми он часто пользуется для различных целей. Может и вам чего пригодится.

4. [post] Как мы переписывали репликацию корзин.

===================================

Год назад я выступал на нашем митапе в Минске с темой про оптимизацию разработки в моей команде. Там была на самом деле серия митапов в разных городах.
В этом году коллеги тоже ездят. На ближайшее время планы такие:
- 15 ноября в Казани:
- про AI-ассистента в Маркете
- про переосмысление поиска лекарств в Еде
- про пересборку инфры Маркета
- !и! про LLM Cache в поиске Лавки
- 22 ноября в Нижнем Новгороде
- про скидки в Еде
- про сохранение консистентности данных о товарах в Маркете (кстати нам сейчас очень релевантно; мы не то чтобы хотим устранять разночтения, но уже движемся в сторону усложнения этого места ради роста гибкости)
- про event-driven цикл заказа в Лавке
- и про алгоритмы логистики в Еде
В обоих городах сверху будут ещё кейслабы, вайбкодинг сессии, код-гольф (обнаружите знакомое лицо тут? :) ) и настолка про разработку.

Регистрация и туда, и сюда по ссылке.

Ну а я принесу вам записи, как только они появятся.

Был кстати в этом году и в Казани, и в Нижнем Новгороде. Понравилось.

===================================

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

#books #ml

System Design. Машинное обучение. Подготовка к сложному интервью. Алекс Сюй, Али Аминиан.

Книга про подготовку к сисдиз интервью в направлении ML.

Структура ожидаемая:
- введение и общие сведения (общая информация про флоу собеседования с пояснениями по каждому этапу)
- 10 глав с разбором различных кейсов по проектированию ML фичей: поиск видео на YouTube, обнаружение вредоносного контента, рекомендации видео/событий/знакомых юзеров и прочее.

Конечно, книга исходно не предназначена для меня. Во-первых, я не мльщик. Просто рядом тусуюсь как с коллегами, так и с друзьями. Во-вторых, мне не нужно проходить подобную секцию. Я скорее взял почитать знакомый формат, чтобы посмотреть, а как там «у них».

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

С точки зрения «я не мльщик» мне понравилось. Некоторые вещи объясняются с нуля, что позволяет осознать концепции (большинство), даже если ранее с ними не встречался. Мне понравилось в качестве материала, который позволяет узнать что-нибудь про базовые мльные системы, пусть даже и на спичках.

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

Важно, что мне именно показалось.

Я попросил друга с опытом в сфере прочитать рандомную главу и поделиться впечатлениями (его LinkedIn). Тезисы от него такие:
- для базового понимания топ
- местами есть формулы, но они не объясняются (т.е. иногда с полученными пояснениями сложно вспомнить, что конкретно она делает)
- над картинками не сильно заморачивались (хочу отметить, что мой друг -- эстет)
- модели вроде поясняются, но недостаточно глубоко. Если бы я не знал, то я бы не вспомнил
- на реальных собесах больше углубляются в матчасть и говорят про ML. Тут же книга ориентируется больше на бизнес-сторону задачи, что, конечно, хорошо, если у тебя мало в этом опыта, но недостаточно покрывает реальные интервью.

И поинт, который я хочу вставить исключительно для души (относится он к русскому переводу, который мы читали):
- «звучит как будто курсовую специально на русский переводили каждое слово».

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

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

Резюмируя, хорошая книга по верхам бизнес-куска ML сисдиза. Так сказать, необходимо, но недостаточно.

Много ещё хвалят Alex Xu книжку про подготовку к классическому сисдизу. Я этого мнения не разделяю. Она тоже сильно оторвана от реальности. Гораздо полезнее сидеть на YouTube и смотреть моки реальных собеседований, желательно Senior+ уровня. Смотреть разборы задач с собеседований. Смотреть про самые популярные технологии и их возможности. Просто потому что любой нормальный видос по теме даст вам гораздо больше практической информации, которую в книгах, почему-то, не пишут.
Наверное потому что писать в книге про детали десяти баз данных некачественно нельзя. Лучше и не начинать.

Читается за 5.5 часов.

6 собеседований из 9.

И анонс от друзей.

22 ноября в Москве пройдёт System Level Meetup от YADRO.

Там 2 трека: regular C++ и C/Linux kernel.
Будем честными, второй меня не сильно интересует, но может кому-то из вас подойдёт.
А в первом каждый первый доклад звучит солидно:
- корутинные оптимизации в компиляторах от Константина Владимирова и коллеги
- про затягивание модулей в существующий проект (Антон Полухин про это рассказывал уже на Zero Cost Conf в этом году, но сейчас такое время, что нам нужно больше позитивного опыта внедрения)
- про production-ready LRU-кеш от Ильи Шишкова
- про оптимизацию kd-tree от Саши Голубева
- про чекеры в clang-tidy от Анастасии Черниковой
- и про строки от Антона Полухина.

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

Ссылочка на регистрацию.

#list

0. [talk] Modernizing Compiler Design for Carbon Toolchain.

Chandler Carruth рассказывает про базовый дизайн современных компиляторов, который уходит в решения 50летней давности, и делится ограничениями такого подхода, после чего рассказывает про новые подходы и решения, применённые при реализации компилятора для Carbon, что позволило научиться компилировать язык очень эффективно и быстро.
Нормальная такая волына этот доклад.

1. [article] Diff Algorithms.

Солидный пост про алгоритмы поиска диффа в текстах (и последовательностях в общем). Автор рассказывает, что он хотел от подобной библиотеки, чем не устраивают существующие на Go, как это всё счастье работает.

Понравилось, что при проектировании API либы автор пошёл от пожеланий юзера и потенциальных хотелок по использованию библиотеки, а не с конца разработчика. Сделать хорошую API даже с точки зрения кода это целое искусство. Я в последнее время всё больше и больше про это думаю. Ничего правда не придумал. Может надо погрузиться в тему глубже.

2. [article] Life Altering Postgresql Patterns.

Набор рекомендаций, которые могут сильно облегчить жизнь при работе с postgres. Там что-то вида: юзайте uuid, всегда имейте created_at и updated_at, юзайте енамы, используйте схемы и др.
Местами база, местами я ещё не думал и не встречал связанных проблем. Но там где встречал, на сто процентов уверен, что рекомендации к месту и не раз экономили мне кучу времени и нервов.

3. [article] Build Your Own Database.

Интерактивный пост, в котором автор пишет простой kv-storage с нуля. Там кнопки свистелки. Люблю формат за наглядность.

4. [article] 500 Miles.

"We're having a problem sending email out of the department."
"What's the problem?" I asked.
"We can't send mail more than 500 miles," the chairman explained.
I choked on my latte. "Come again?"

===================================

27 ноября в Екатеринбурге будет Pytup от коллег.
Мероприятий в регионах не так много, потому можно и сгонять. Тем более должно быть интересно.
Ссылочка на регистрацию.

===================================

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

#list

0. [talk] What Every Programmer Should Know about How CPUs Work.

Matt Godbolt наваливает баса и рассказывает базу про устройство CPU. Я не очень погружён, потому мне понравилось. Хороший кусок уделяется общему пайплайну, branch predictor'у и ещё немного execute инструкций.

1. [article] The Art of Formatting Code.

Статья про форматирование кода, правда в итоге не кода, а JSON, но поверьте, этого с головой достаточно.
Примеры кстати на Rust. Довольны???

2. [article] Expert Generalists.

Martin Fowler с друзьями рассказывает про концепцию expert generalists: кто такие, какие качества, зачем нужны, как оценить, как растить и ещё пару мелочей.

3. [talk] Анатомия асинхронных движков.

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

Это кстати C++ Zero Cost Conf 2021. Первая.

4. [article] How to Increase Your Luck Surface Area.

Нравится вам это или нет, важно говорить про то, что вы делаете. Современные иерархии в больших компаниях не могут естественным образом привести к тому, что про ваши успехи будут знать все вокруг (а это чаще всего жизненно необходимо для ваших финансовых результатов). Так что надо идти и как-то рассказывать про успехи.
В конце очень хорошая картинка. У вас есть несколько вариантов, но показательнее всего мне кажется такая развилка: можно либо делать достаточно, но правильно и много про это говорить (best), либо делать очень много и почти про это не говорить (тоже best, но другой ценой).
Языком чесать не мешки ворочать, как известно. Так что делитесь время от времени своими успехами (и не только).

================================

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

#list

0. [talk] The Evolution of std::optional - From Boost to C++26.

Начинается сезон CppCon2025.

Steve Downey рассказывает про std::optional и, что больше ему свойственно, т.к. он там что-то предлагает по теме в стандарт, std::optional<T&>. Там общие концепции, сложные вопросы "как должны себя вести в ситуациях А Б В". Что делать с такими-то методами.
И местами приятные примеры кода из C++-современного/C++-будущего. Повышаем насмотренность. Набиваем руки.
Что прикольно, докладчик рассказывает про профит от участия в Beman project: нашли багу в потенциальной реализации std::optional<T&>.

1. [article] Итоги встречи ISO C++ на Гавайях: начинаем полировку стандарта С++26.

Антон Полухин рассказывает новости очередной встречи комитета.

2. [article] Metastable Failures in the Wild.

Я вам уже рассказывал про metastable failures и Лёшу Быкова (@it_tldr). Добрался осознанно перечитать некоторые статьи из ссылок в его докладе.
Метастатья про разные найденные на просторах инциденты, связанные как раз с metastable failures. Там общие описания, небольшая статистика (например, в >50% случаев, ретраи были фактором, мещающим системе самовосстановиться) и разбор деталей некоторых инцидентов. Что забавно, есть такой кусок:

While publicly available incident reports provide enough high-level information to identify the metastable failures, they lack the depth and detail to understand the complex interactions between components in large systems. In this case study, we use insider information to describe in detail one specific metastable failure occurring at Twitter, a large internet company, due to garbage collection (GC).

Т.е. кто-то ребятам nda слил, а они и рады это описать. Похехал.

3. [article] Код-гольф в Яндексе: как нерды развлекаются.

Помните, я вам писал про военный синус от Паши Сухова?
Паша весь этот год прикладывал (и продолжает) руку к активностям на митапах и конференциях Яндекса. Делает код-гольф. Не знаете что это? Примеры задач и решений не видели? Ну почитайте его статью!

А ещё, прикиньте, он услышал запросы трудящихся и дропнул канал себе: @cpp_durka. Ничего не обещает, но вы приходите.

4. [book] Корпорация гениев. Как управлять командой творческих людей. Эд Кэтмелл.

Это не обзор в обычном смысле. Просто поделюсь наблюдением.

Книжка рассказывает про молодые годы Pixar, как чуваки искали своё место на рынке, Стива Джобса и процессы в компании.
И хотя Pixar когда-то давно это совсем не айтишечка, там можно увидеть знакомые сегодня штуки.
Например у чуваков был brain trust -- собрание ответственных коллег, которые ревьюили разные решения в производстве мультиков у ответственных. Я, слушая, подумал "Пфф, это ж архитектурное ревью. Мы такое сто лет у себя уже делаем".
Или автор рассказывает про то, как случайно удалили огромный кусок работы, запаниковали, нашли бекап недельной давности у коллеги дома, восстановили и сели думать, как такого больше не допустить. Не винили ответственного. Сделали какие-то action item'ы для неповторения. Тут я подумал "Пфф. Чуваки придумали инцидент менеджмент. Что ж тут такого?".
А потом я осознал, что это мне в 2к25 всё понятно и очевидно. А у них не было примеров. Им некуда было смотреть. Они буквально чуть ли не первые, кто начал делать подобные вещи и сделал из них процессы. А потом уже спустя 10-15-20 лет я считаю это базой.
Сложно воспринимать идеи из прошлого. Надо осознанно заставлять себя возвращаться в то время, в тот контекст. Особенно сложно, когда ты не знаешь контекста. Но если получается, иногда всё-таки можно ощутить прорыв.

================================

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

=====

Картинка кринж или норм?

#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 в разных плоскостях по разным оптимизациям. Может быть полезно, если хотите осознать, какой компилятор лучше под ваши конкретные нужды, т.к. трейдофы выбирают разные.

#list

0. [talk] Cutting C++ Exception Time by 93.4%.

Khalil Estell рассказывает про то, как он срезает косты при использовании икслючений на железках.
Как настоящий сварщик, он взял самые жирные куски и по одному их поускорял. Причём ускорения довольно прикольные. Местами их сложность примерно около нуля. Но это ж надо было додуматься всё равно!
Ещё чувак очень естественно выглядит на сцене. Мегауверенно. Будем у него учиться.

1. [article] C++20 idioms for parameter packs.

Солиднейшая статья про variadic templates.
Первая треть фокусируется на базе: какие бывают, где можно писать, где нельзя (рекомендую вчитаться, даже если разбираетесь; я нашёл для себя несколько интересностей).
Вторая-третья на идиомах, которые сегодня помогают делать красивое полезное.
Местами ту мач формальная, но я давно убеждён, что C++ сообщество -- сборище душных персон, которые за незнание каждой буквы в стандарте готовы публично растерзать (я сам душный, но не настолько, к счастью).

2. [article] How does it work - The Log-Structured Merge (LSM) Tree.

Там немного пролистайте вниз к теме.

3. [talk] Intro to Large Language Models.

Лекция двухлетней давности от Andrej Karpathy про устройство LLM, как они живут, учатся и ломаются.
Кажется, это что-то фундаментальное на года, что можно будет ещё детям показать для общего развития.

4. [fact] std::optional::value

Смотрел Understanding Optimizers: Helping the Compiler Help You, в котором докладчик говорит про то, что код с std::optional вида

if (x) y = x.value()

превращается в

if (x.m_active) {
  if (x.m_active) {
    y = x.m_data;
  } else { throw ...; }
}

И он прав. Это прям хороший наглядный пример лишнего чека и нашего с вами перфа. Но вопрос не только в двойной проверке. Вопрос в исключении. Мы у себя стараемся юзать std::optional::value просто потому что когда проверка вдруг потерялась, вы полусаете адекватное исключение с понятной ошибкой. Да, проблему надо ещё поискать, но по крайней мере понятно, что искать.
Проверку потерять нереально? Конечно это не так. Код бывает разный. Рефакторинги регулярными. Вообще на раз два.
Короче делаем трейдоф перфоманс-скорость дебага проблем в сторону последнего.

Правда я умолчал о важном моменте. Докладчик всё-таки отмечает, что компилятор не делает лишних проверок. Всё там в порядке.

=============================

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