Размышлизмы eao197

О блоге

2030-01-01T00:00:00.002+03:00

Более тридцати лет я занимался разработкой ПО, в основном как программист и тим-лид, а в 2012-2014гг как руководитель департамента разработки и внедрения ПО в компании Интервэйл (подробнее на LinkedIn). В настоящее время занимаюсь развитием компании по разработке ПО stiffstream, в которой являюсь одним из соучредителей. Поэтому в моем блоге много заметок о работе, в частности о программировании и компьютерах, а так же об управлении.

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

[life.photo] Характерный портрет: вы и ваш мир моими глазами. Безвозмездно :)

2029-12-31T10:53:00.000+03:00

Вы художник? Бармен или музыкант? Или, может быть, коллекционер? Плотник или столяр? Кузнец или слесарь? Владеете маленьким магазинчиком или управляете большим производством? Реставрируете старинные часы или просто починяете примус? Всю жизнь занимаетесь своим любимым делом и хотели бы иметь фото на память?

Предлагаю сделать портрет в обстановке, связанной с вашей работой или увлечением. Абсолютно бесплатно. Очень уж мне нравится фотографировать людей в их естественной среде. Происходить это может так...

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

Если вы заинтересовались, то связаться со мной можно по мейлу eao197 на gmail точка com или в Skype по имени eao197. Либо же оставив комментарий к этой записи. Или в соцсетях: VK, Facebook.

Для съемки мне нужно знать в каких условиях будет проходить фотосессия: помещение или открытое пространство, темно там или светло, можно ли использовать вспышку или это будет невозможно в принципе и т.д. Если мое присутствие на вашем рабочем месте или рядом с ним требует какого-то предварительного согласования -- то вам самим нужно будет позаботиться об этом. Ну и было бы желательно, чтобы ваши коллеги и клиенты были в курсе и не протестовали бы против попадания в кадр.

Во избежание чрезмерных ожиданий хочу сразу предупредить: я всего лишь любитель, не проффи. Поэтому результат не гарантирован. По опыту, для того, чтобы получился хороший портрет, приоткрывающий характер человека, нужен не один дубль, и даже не десять, а то и не сто. Ориентироваться нужно на 3-4 часа общения и фотосьемки, что выльется в несколько сотен кадров из которых будет отобрано всего несколько штук. Так что вам потребуется немного терпения, а мне -- капелька удачи.

Вот пример того, что может получаться в результате таких съемок:

кукольных дел мастер Екатерина Katiedda Минакова;
саксофонист Анатолий Аксёнов
резчик по дереву Виктор Россолов;
уникальный гармонист Вячеслав Сивуха;
кузнец Дмитрий Андреев;
реконструктор Виталий Медведев

Вот еще несколько примеров того, что получалось в прошлом:

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

[prog.sarcasm] Если долго сидеть на берегу, то можно увидеть как Erlang-еры...

2026-08-10T08:42:29.532+03:00

...переписывают свой софт на Rust:

Моя идея о том, чтобы переписать наш Flussonic с Erlang на Rust оказалась совершенно прекрасной и у меня совершенно прекрасные результаты. Захват 10 000 камер на сервер - это прямо скажем серьезный результат, на рынке таких предложений мало.

Это слова Макса Лапшина, одного из самых известных пользователей Erlang-а в Рунете (ссылки на пару статей которого были даже у меня в блоге). Он же и автор мема о том, что писать на С++ -- это выгребать корки по утрам.

Сколько было в прошлом разговоров о том, насколько хорош Erlang и насколько Erlang подходит и для таких задач, где, казалось бы, C++у самое место, а не одному из самых медленных динамически-типизированных языков. И все это для того, чтобы в итоге отказаться от Erlang-а в пользу нативного компилируемого языка, прямого конкурента С++ по производительности и ресурсоемкости.

Upd.В этой теме на LOR-е еще прекрасное добавилось от Лапшина (это ответ на вопрос уперся ли Erlang в потолок производительности):

Во все потолки, какие можно было.
И производительность, и количество библиотек, и количество людей и всё прочее.
Когда стало ясно, что прийдется самому руками писать QUIC, тут я слегка устал от эрланга.
О перфомансе вида «принять 10 000 камер» и речи не идет, причем если бы не медленный сторадж, новый код можно поковырять и до 20 тыс (просто это не нужно).

При всем моем уважении к Erlang-у и людям, которые его создали, но такие факторы, как "производительность" и "количество людей", как по мне, так были очевидны много-много лет назад.

Если говорить серьезно, то когда вам повезло работать на проекте в течении 10-15-20 и более лет, то у вас есть возможность наблюдать за тем, как принятые вами же решения, которые когда-то давно казались крутыми и удачными, через годы не просто перестают такими быть, а нуждаются в замене на что-то, что сейчас кажется крутым и удачным (и далее по рекурсии).

[life.audiophile] Неожиданно приятное открытие в VE Megatron

2026-08-04T08:46:14.350+03:00

Несколько лет назад попал ко мне в руки USB-ЦАП Megatron от Venture Electronics (хороший обзор на него можно посмотреть здесь: YouTube или RuTube). Попасть-то попал, но большую часть времени лежал без дела. По звуку с ним все OK, но требует, зараза, высокоомные наушники. Мои вкладыши на 300ом приходится слушать на минимальной громкости.

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

А вот буквально на днях случайно выяснилось, что по 3.5mm разъему Megatron поддерживает гарнитуру!

И это решило проблему, с которой мне приходилось мириться на протяжении многих месяцев. А именно: на работе я подключаю к компьютеру USB-ЦАП чтобы слушать музыку в наушниках. Но когда возникает необходимость рабочего созвона через какой-то мессенджер или Zoom/Telemost, то приходится переключаться на гарнитуру, которая втыкается в 3.5mm разъем компьютера. И это переключение я регулярно забываю делать. Не говоря уже о том, что сама по себе эта необходимость раздражает.

Но, к счастью, Megatron делает все эти манипуляции ненужными. Достаточно в 3.5mm разъем Megatron-а воткнуть наушники с гарнитурой, в 4.4mm (или 2.5mm) разъем -- наушники для музыки, а сам Megatron по USB подключить к компьютеру. И все. Слушаешь себе спокойно музыку (хоть из локального хранилища, хоть со стримминга), а когда нужно созвониться, то просто берешь другие наушники, подключенные к тому же самому Megatron-у и все.

PS. Почему для музыки и для созвонов разные наушники? Ну просто так получатеся, что дорогие динамики я не ставлю в наушники с гарнитурным кабелем. Эти кабеля не самые надежные и за пару-тройку лет выходят из строя (а то и раньше, тут как повезет с качеством самого гарнитурного блока). А менять кабель все-таки спокойнее, когда ты знаешь, что динамики дешевые и если случайно повредишь при разборке наушников, то сильно обидно не будет.

[life.cinema] Очередной кинообзор (2026/07)

2026-08-01T08:34:44.697+03:00

Традиционный отчет о просмотренных за минувший месяц фильмах. Традиционно в начале каждого из списков идет то, что понравилось больше, а в конце то, что не понравилось вообще. В целом же почти ничего не могу рекомендовать, большая часть отсмотренного оказалаь "ну такое себе" 😣

Фильмы

День разоблачения (Disclosure Day, 2026). Не ждал ничего выдающегося и получил приятный для просмотра фильм. Наблюдать за происходящим было интересно, в финале ожидал чего-то подобного (до сих пор помню разочарование от финала "Близких контактов третьей степени" того же автора), поэтому в этом моменте разочаровать меня кино не смогло. В целом, на фоне остального выходящего сейчас шлака, очень даже приличный фильмец.

Стервятники (Vultures или Rapaces, 2025). Тот самый случай, когда от кино вообще ничего не ждешь, а получаешь вполне нормальный фильм. Не шедевр, но крепкий середнячок.

Грязные деньги (Deoreowoon done sondaeji mara, 2023). Если бы не специфика азиатской актерской игры, то был бы крепкий середнячок в стиле криминальной драмы с интересной развязкой.

Кто-то должен умереть (2025). Отличная картинка. Хорошие актеры. Любопытный сюжет. Но авторам не удалось создать атмосферу настоящей реальности -- смотришь на происходящее на экране и не можешь поверить что такое может происходить на самом деле.

Бескрайняя ночь (The Vast of Night, 2019). Если вы любитель артхаусного и фестивального кино, то можете попробовать глянуть. Мне лично не зашло.

Глубокие воды (Deep Water, 2026). Очень и очень бюджетно. Лучше обойти мимо и не тратить свое время.

Смерть Робина Гуда (The Death of Robin Hood, 2026). Унылая тягомотина с непонятным для меня замыслом и невнятным сюжетом.

Сериалы

Во всем виновата она (All Her Faul, первый сезон, 2025). Отличный подбор актеров. Как по мне, так по некоторым ролям попадание 100%. Не самая плохая развязка, хотя к некоторым важным моментам остаются вопросики. Однако, мне показалось, что фильм безбожно растянут. Если бы вместо 8 серий было 4, получилось бы хорошо, а так скучновато.

Я тебя отыщу (I Will Find You, первый сезон, 2026). Актеров хороших собрали. И они играют. Но это единственное хорошее, что есть в сериале. Когда начинаешь вдумываться в сюжет, то оказывается, что нам втирают какую-то дичь.

Минута тишины (первый сезон, 2024). Очень картонные персонажи, очень все шаблонно, местами приторно-елейно. Но в целом не самый плохой сериал.

Побег (Run, первый сезон, 2026). Главным достоинством сериала является то, что в нем всего шесть небольших серий. Для меня главный вопрос -- как историю преступника с несколькими десятками успешных ограблений и двумя побегами из тюрьмы превратили в такую нудную мелодраму. Смотреть можно только ради того, чтобы полюбопытствовать а как же снимают кино в Австралии. Есть здесь какой-то свой стиль, отличный от голливудского.

После Фишера. Инквизитор (2026, это же третий сезон "Фишера"). Редкая муть, смело можно пройти мимо.

Кино вне категории

"Человек кусает собаку" или "Это случается рядом с вами" (C'est arrivé près de chez vous, 1992). Самое необычное кино из тех, что посмотрел за последние несколько лет. Рекомендовать не буду т.к. ну очень уж специфическое. Однако, на фоне сегодняшнего широпотреба выглядит более чем необычно.

[prog.thoughts] Так как же ИИ может изменить профессию "программист"?

2026-07-31T23:01:17.360+03:00

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

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

Во-первых, это экономическая и политическая обстановка в мире. Если не будет какого-то катаклизма, сравнимого с Первой или Второй Мировыми войнами, если мировая экономика выберется из кризиса и вернется экономический рост, то у программистов в целом все будет ОК. Будет работа, которая, наверняка, сильно изменится. Но эта самая работа хотя бы будет. А вот если мир скатится во что-то вроде Великой Депрессии в США 1930-х годов, или периода Веймарской республики начала 1920-х годов, то увы. Всем будет очень и очень не очень. В том числе и программистам. А может быть программистам как раз в первую очередь.

Во-вторых, это экономика конкретных ИИ-компаний, которые сейчас пытаются поделить глобальный рынок ИИ-инструментария. Говорят (говорят!), что пока что экономика у них не сходится, что они глубоко убыточны и что непонятно какова должна быть реальная стоимость их услуг для того, чтобы окупить многомиллиардные инвестиции. Если получится, что реальная рыночная цена на этот самый ИИ будет сравнима со стоимостью обычного человека, то на какое-то время программистам можно будет облегченно выдохнуть.

Еще, конечно же, интересный вопрос в том, до какого уровня качества этот самый ИИ в итоге дойдет. Пока все говорят (говорят!), что ИИ с каждой новой версией становится все лучше и лучше. Хотя внешней публике и не видно во что (по деньгам инвесторов) эти улучшения обходятся.

А то ведь может оказаться, что с ИИ такая же ситуация, как с аудиофилией: очень несложно и совсем не дорого дойти до 90% от теоретически возможного качества звука. Зато стоимость каждого следующего процента качества возрастает в геометрической прогрессии. Может и с ИИ так? Может мы еще даже до 90% не дошли. И каждая следующая ступень качества, когда модели будут выдавать более точные решения и меньше галлюцинировать, будет обходиться на порядок дороже предыдущей. Чтобы в итоге стало не выгодно вкладывать деньги в повышение этого самого качества.

Ну да ладно, давайте представим, что Третьей Мировой на наше счастье не случится и ИИ продолжит развиваться семимильными шагами без роста стоимости.

Думаю, что тогда наша профессия изменится. Быстро и бесповоротно.

Но не исчезнет.

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

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

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

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

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

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

[prog.thoughts] Надобность в "инфраструктурниках" из-за того, что людям приходилось писать код самим

2026-07-30T18:54:00.952+03:00

Продолжу то, что начал ранее.

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

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

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

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

Получается, что чем более сложную задачу нам нужно решить, тем большим количеством более мощных абстракций мы должны располагать. Будь то языковые конструкции (вроде классов или шаблонов/дженериков) или библиотеки готовых "компонентов". А воплощение в жизнь подобных абстракций -- это именно что работа инфраструктурных программистов. Кто-то из инфраструктурщиков развивает языки программирования для того, чтобы поднять уровень и дать возможность выражать в коде все более и более сложные вещи, при этом обеспечивая и надежность, и удобство (если не брать в рассмотрение C++, конечно же). Кто-то пишет библиотеки и фреймворки. Кто-то создает вспомогательные инструменты вроде flex/bison или ANTLR.

В итоге прикладные программисты получают в свое распоряжение все больший и больший набор средств. Что дает возможность писать все более и более объемные и сложные программы. Делать это быстрее, с меньшими усилиями и с более предсказуемым результатом (если не брать в рассмотрение C++, конечно же).

Или может быть лучше сказать "получали"?

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

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

Однако, вряд ли эта самая абстракция необходима ИИ. Написали в спецификации о том, что какие-то данные должны быть упорядочены по какому-то критерию и для ИИ этого уже достаточно. Каким образом данное требование будет отображено в коде -- реализацией сортировки "по месту" или обращением к какой-то готовой функции -- безразлично, это всего лишь деталь реализации. Для каких-то хорошо известных и многократно повторенных задач ИИ будет переиспользовать уже написанный когда-то людьми код. Для чего-то более экзотического ИИ сгенерирует что-то свое. Что это будет и будет ли это соответствовать тем же самым критериям "хорошего" кода (простота, читаемость, сопровождаемость) не суть важно, т.к. скорее всего людям и не придется заглядывать в сгенерированный код в подавляющем большинстве случаев.

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

Это люди могли набить шишки на return -1, прийти к выводу, что исключения надежнее, потом собрать кучу граблей с исключениями, прийти к выводу, что нужен симбиоз, изобрести синтаксис `?` в Rust и try в Swift...

Чтобы в итоге этих самых людей заменил ИИ, который будет генерить простыни Go-шного кода с примитивнейшим `if err != nil` ничуть не страдая от того, что это и многословно, и отвлекает внимание, и не обеспечивает достаточной надежности.

Продолжение.

[prog.thoughts] Мое деление программистов на "прикладных" и "инфраструктурных"

2026-07-29T07:28:02.197+03:00

Чтобы продолжить рассуждения о том, как ИИ может повлиять на будущее профессии "программист" (начатые здесь и продолженные здесь) придется озвучить одну из классификаций программистов, которой придерживаюсь в последние годы.

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

Инфраструктурные программисты делают инструменты, которые используют прикладные программисты в своей работе. Самыми яркими примерами таких инструментов являются фреймворки и библиотеки. Как общего назначения (вроде Qt, JDK или .NET Framework), так и какие-то специализированные, заточенные под конкретный проект.

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

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

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

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

Яркий пример, демонстрирующий разность в подходах, довелось увидеть буквально пару дней назад в докладе «Опыт перехода проекта „Авито.Доставка“ с Java на Go» / Илья Лапин, Сергей Поляков (Avito), который мне YouTube зачем-то подсунул в рекомендациях (но оказалось довольно любопытно, благо доклад короткий и толковый):

Суть в том, что на момент доклада (2018-й год) в стандартной библиотеке Go (как и в самом языке) не было такого понятия как "множество" (оно же Set). Понятие "словарь" встроенное в сам язык было (в виде штатного типа map), а вот "множества" -- нет.

Прикладной программист: ну OK, раз нет "множества", то сойдет и "словарь", просто в качестве значения для ключа будет использоваться экземпляр пустой структуры. Не, ну а чё, работает же.

Тогда как инфраструктурный программист от подобного впадает в ступор. Типа: "а почему этот самый Set нельзя было взять и сделать?" 😉

PS. Убедительная просьба не воспринимать этот текст как попытку ранжирования программистов по их качеству. Типа "прикладные" программисты -- не настоящие программисты вовсе, тогда как "инфраструктурные" -- соль профессии и настоящая илитарная илита. Как раз жизнь учит тому, что все программирование живет и зарабатывает исключительно благодаря "прикладным" программистам, тогда как "инфраструктурые" являются всего лишь обслуживающим персоналом (но без этого обслуживающего персонала тоже нельзя).

Продолжение.

[prog.thoughts] И еще одна мысль про влияние ИИ на программирование

2026-07-28T10:08:02.764+03:00

Навеяно вот этой статьей: Английский вместо кода

Когда я приходил в профессию на программиста возлагались следующие задачи:

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

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

Никаких бизнес-аналитиков и тестировщиков в то время в наших палестинах еще не существовало как класса, появилось все это лет на 5-10 позже (хотя на Западе, как я слышал, к началу 1990-х все это уже было). Ну да не суть.

Суть же в том, что для некоторых настоящее программирование заключалось прежде всего в "воплотить решение в коде" + (кому-то в больше степени, кому-то в меньшей) "решить как именно сделать" и "протестировать сделанное" (иногда в формулировке "заставить это все работать в конце-то концов!"). А общение с заказчиком и формирование ТЗ было худшим из периодов и настоящим наказанием.

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

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

Только вот для некоторых это уже не будет тем самым настоящим программированием от которого эти некоторые получали наибольший кайф и в котором пытались достичь своего наивысшего мастерства.

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

Как по мне, так это уже и не программирование вовсе.

[prog.thoughts] Подумалось тут про ИИ и будущее программирования...

2026-07-27T16:29:51.442+03:00

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

В связи с этим подумалось, что наступает золотая эпоха тех специалистов, которые были вынуждены программировать ну хоть как-то. Вроде физиков, химиков и биологов, которым нужно было делать вычислительные эксперименты, для чего приходилось осваивать программирование хотя бы в минимальной степени. В лучшем случае на Python или Pascal, но скорее на Fortran, а в особо запущенных случаях и на С++.

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

PS. Прошу не воспринимать вышесказанное как прогноз, не нужно запоминать этот твит. На самом деле данный пост начинался как большой и глубоко пессимистический текст с самыми мрачными фантазиями о недалеком будущем. Но потом я решил, что лучше бы попробовать найти в происходящем что-нибудь хорошее 🙂

[prog.c++.multithreading] Сломал себе мозг пытаясь понять что не нравится thread sanitizer-у

2026-07-25T14:24:49.261+03:00

Upd. Похоже, что проблема сперва была в том, что SO-5 подключался в проект через vcpkg и когда проект компилировался с TSan, то линковался SO-5, собранный без TSan. А когда я включил исходники SO-5 в сам проект, чтобы все компилировалось с одинаковыми ключами, то ошибся с порядком команд в CMakeLists.txt и при компиляции SO-5 опции для TSan не учитывались. Если же собрать и SO-5, и остальной проект с одинаковыми опциями, то данной проблемы не возникает (пока?).

В текущем проекте thread sanitizer периодически выдает предупреждение о data race на фрагменте, который относится к SObjectizer-у.

Самое плохое то, что:

я не понимаю в чем именно thread sanitizer видит проблему. Соответственно, неизвестно, является ли срабатывание TSan-а ложно позитивным или же есть реальная ошибка, которую следует исправить;
мне не удается повторить такую же ситуацию в тестах для самого SO-5. Т.е. в рамках проекта TSan диагностику выдает, а в мелких тестах, которые пытаются повторить тот же сценарий -- нет. Ни в какую. Что сильно затрудняет разбирательства и поиск обходных путей.

Что здесь происходит:

Агент на нити T7 отсылает сообщение GiveMeTask агенту-координатору, который работает на нити T3.

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

В это же время на нити T7 завершается процедура отсылки сообщения.

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

Экземпляр сообщения GiveMeTask создается на нити T7. Указатель на этот экземпляр хранится на нити T7 внутри объекта intrusive_ptr_t.

На нити T3 внутри execution_demand_t так же есть свой объект intrusive_ptr_t который хранит указатель на этот же экземпляр GiveMeTask.

Т.е. на двух нитях есть два разных intrusive_ptr_t, которые хранят в себе указатель на один и тот же объект GiveMeTask.

При этом счетчик ссылок на GiveMeTask хранится в самом объекте GiveMeTask. Класс GiveMeTask наследуется от so_5::message_t:

struct GiveMeTask final : public so_5::message_t
{
    const so_5::mbox_t _workerMbox;

    GiveMeTask(so_5::mbox_t workerMbox)
        : _workerMbox{ std::move(workerMbox) }
    {}
};

А so_5::message_t наследуется от so_5::atomic_refcounted_t:

class message_t : public atomic_refcounted_t
    {
        ...
    };

В so_5::atomic_refcounted_t счетчик ссылок хранится в виде std::atomic. Т.е. операции инкремента-декремента количества ссылок происходят атомарно и не нуждаются в дополнительной синхронизации.

Получается, что на нити T7 создается новый экземпляр GiveMeTask, указатель на него сохраняется в локальном объекте intrusive_ptr_t и счетчик ссылок на GiveMeTask выставляется в 1.

На нити T7 вызывается send для GiveMeTask и формируется execution_demand_t для агента-координатора. Внутри execution_demand_t создается свой intrusive_ptr_t и счетчик ссылок для GiveMeTask получает значение 2.

Затем на нити T3 происходит обработка GiveMeTask, после чего начинается разрушение execution_demand_t и его содержимого (в том числе и второго intrusive_ptr_t).

Но чуть раньше на нити T7 происходит разрушение своего intrusive_ptr_t после чего счетчик ссылок в GiveMeTask опускается до 1.

А уже после этого на нити T3 счетчик ссылок на GiveMeTask обнуляется и происходит разрушение объекта GiveMeTask.

Происходят действия именно в этом порядке. Если бы сперва полностью разрушился execution_demand_t на нити T3 и лишь после этого началось уничтожение intrusive_ptr_t на нити T7, то деструктор GiveMeTask вызвался бы на нити T7, а не на нити T3.

Т.е. с моей точки зрения здесь все OK. Но TSan видит data race. А я не понимаю про какой data race идет речь.

Под катом выхлоп от TSan в текстовом виде.

WARNING: ThreadSanitizer: data race (pid=105293)

  Write of size 8 at 0x720800038028 by thread T3:

    #0 operator delete(void*, unsigned long) ../../../../src/libsanitizer/tsan/tsan_new_delete.cpp:150 (libtsan.so.2+0xa66c8) (BuildId: 2a13a7710e361d06f7babbea53065ca2be93f738)

    #1 Calculation::CoordinatorImpl::GiveMeTask::~GiveMeTask() /home/eao197/sandboxes/<censored>/include/CalculationCoordinatorAgents.h:23 (<censored>+0x1420c2a) (BuildId: d95e75b5663cd24e4ecc0f7a4ab2777babe82359)

    #2 so_5::intrusive_ptr_t<so_5::message_t>::dismiss_object() /home/eao197/sandboxes/<censored>/so_5/atomic_refcounted.hpp:322 (<censored>+0x16ac5db) (BuildId: d95e75b5663cd24e4ecc0f7a4ab2777babe82359)

    #3 so_5::intrusive_ptr_t<so_5::message_t>::~intrusive_ptr_t() /home/eao197/sandboxes/<censored>/so_5/atomic_refcounted.hpp:178 (<censored>+0x16ac5db)

    #4 so_5::execution_demand_t::~execution_demand_t() /home/eao197/sandboxes/<censored>/so_5/execution_demand.hpp:61 (<censored>+0x16ac5db)

    #5 void std::destroy_at<so_5::execution_demand_t>(so_5::execution_demand_t*) /usr/include/c++/13/bits/stl_construct.h:88 (<censored>+0x16ac5db)

    #6 void std::allocator_traits<std::allocator<so_5::execution_demand_t> >::destroy<so_5::execution_demand_t>(std::allocator<so_5::execution_demand_t>&, so_5::execution_demand_t*) /usr/include/c++/13/bits/alloc_traits.h:560 (<censored>+0x16ac5db)

    #7 std::deque<so_5::execution_demand_t, std::allocator<so_5::execution_demand_t> >::pop_front() /usr/include/c++/13/bits/stl_deque.h:1580 (<censored>+0x16ac5db)

    #8 so_5::disp::reuse::work_thread::details::no_activity_tracking_impl_t::serve_demands_block(std::thread::id, std::deque<so_5::execution_demand_t, std::allocator<so_5::execution_demand_t> >&) /home/eao197/sandboxes/<censored>/so_5/disp/reuse/work_thread/work_thread.hpp:448 (<censored>+0x16ac5db)

    #9 so_5::disp::reuse::work_thread::details::work_thread_template_t<so_5::disp::reuse::work_thread::details::no_activity_tracking_impl_t>::body() /home/eao197/sandboxes/<censored>/so_5/disp/reuse/work_thread/work_thread.hpp:705 (<censored>+0x16ac5db)



  Previous atomic write of size 8 at 0x720800038028 by thread T7:

    #0 std::__atomic_base<unsigned long>::operator--() /usr/include/c++/13/bits/atomic_base.h:410 (<censored>+0x141ff80) (BuildId: d95e75b5663cd24e4ecc0f7a4ab2777babe82359)

    #1 so_5::atomic_refcounted_t::dec_ref_count() /home/eao197/sandboxes/<censored>/so_5/atomic_refcounted.hpp:80 (<censored>+0x141ff80)

    #2 so_5::intrusive_ptr_t<so_5::message_t>::dismiss_object() /home/eao197/sandboxes/<censored>/so_5/atomic_refcounted.hpp:317 (<censored>+0x141ff80)

    #3 so_5::intrusive_ptr_t<so_5::message_t>::~intrusive_ptr_t() /home/eao197/sandboxes/<censored>/so_5/atomic_refcounted.hpp:178 (<censored>+0x141ff80)

    #4 void so_5::low_level_api::deliver_message<Calculation::CoordinatorImpl::GiveMeTask>(so_5::message_delivery_mode_t, so_5::abstract_message_box_t&, std::type_index, std::unique_ptr<Calculation::CoordinatorImpl::GiveMeTask, std::default_delete<Calculation::CoordinatorImpl::GiveMeTask> >) /home/eao197/sandboxes/<censored>/so_5/mbox.hpp:393 (<censored>+0x141ff80)

    #5 void so_5::impl::instantiator_and_sender_base<Calculation::CoordinatorImpl::GiveMeTask, false>::send<so_5::intrusive_ptr_t<so_5::abstract_message_box_t> const&>(so_5::intrusive_ptr_t<so_5::abstract_message_box_t> const&, so_5::intrusive_ptr_t<so_5::abstract_message_box_t> const&) /home/eao197/sandboxes/<censored>/so_5/send_functions.hpp:59 (<censored>+0x141ff80)

    #6 void so_5::send<Calculation::CoordinatorImpl::GiveMeTask, so_5::intrusive_ptr_t<so_5::abstract_message_box_t> const&, so_5::intrusive_ptr_t<so_5::abstract_message_box_t> const&>(so_5::intrusive_ptr_t<so_5::abstract_message_box_t> const&, so_5::intrusive_ptr_t<so_5::abstract_message_box_t> const&) /home/eao197/sandboxes/<censored>/so_5/send_functions.hpp:231 (<censored>+0x141ff80)

    #7 Calculation::CoordinatorImpl::Worker::so_evt_start() /home/eao197/sandboxes/<censored>/src/model/calc/CalculationCoordinatorAgents.cpp:30 (<censored>+0x141ff80)

    #8 so_5::agent_t::demand_handler_on_start(std::thread::id, so_5::execution_demand_t&) /home/eao197/sandboxes/<censored>/so_5/agent.cpp:1433 (<censored>+0x1671404) (BuildId: d95e75b5663cd24e4ecc0f7a4ab2777babe82359)

    #9 <null> <null> (libstdc++.so.6+0xecdb3) (BuildId: 753c6c8608b61d4e67be8f0c890e03e0aa046b8b)

[prog.flame] Узнал давеча о переписывании какого-то Bun с какого-то Zig на какой-то Rust :)

2026-07-22T07:37:23.878+03:00

Т.к. я не тормоз, а всего лишь медленный газ, то только вчера узнал об очередном скандале на просторах этого нашего Интернета. Если кто-то, как и я, все еще не в курсе, то:

Некий проект Bun (говорят, что это какой-то очень и очень быстрый инструментарий для JavaScript, включая и виртуальную машину) внутри Antropic-а переписали с Zig на Rust посредством нескольких десятков параллельно работавших в течении 11 дней агентов: https://bun.com/blog/bun-in-rust

На рассказ об этой процедуре среагировал разработчик языка Zig и высказался в том духе, что ~~баба с возу кобыле легче~~ переписали на Rust и славно, а то эти Bun-овцы уже изрядно задолбали дискредитацией всего Zig-а низким качеством своего кода: https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.html

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

Но больше всего интересует вот какой момент. В блог-посте про переписывание с Zig на Rust приводится пример кода на Zig, который иллюстрирует заморочки, с которыми приходилось сталкиваться Bun-овцам при написании надежного кода на Zig:

fn foo(a_ptr: SharedPtr(TCPSocket)) !void {
  const a: *TCPSocket = a_ptr.get();
  defer a_ptr.deref();

  const b = try do_something_with_a(a);
  defer b.deref();

  // ...
}

Поскольку я не знаю Zig, то очень интересно, а это прям идиоматический код и лучше на Zig уже не получится? Или же это откровенный говнокод, низкое качество которого очевидно даже начинающим Zig-ерам?

PS. Так же я не полностью согласен с тезисом, что для C++ надежность кода достигается за счет следования какому-то административно утвержденному code style (как в случае с упомянутым в блог-посте от Bun-овцев Google C++ code style guide). Многие проблемы (вроде контроля времени жизни объектов, находящихся в совместном использовании) должны решаться не соглашениями, а типами (вроде unique_ptr, shared_ptr и т.д.) Но кто я такой, чтобы рассуждать на эту тему? 😉

PPS. А Rust подтверждает свою репутацию языка, на котором ничего нового не пишут, а только переписывают существующее 🤣

[prog.c++.multithreading] Мой способ обойти ложное срабатывание в TSan с инверсией порядка захвата mutex-ов

2026-07-17T07:24:17.910+03:00

Продолжение вчерашней темы с ложно позитивным срабатыванием thread sanitizer, когда TSan ошибочно диагностировал инверсию порядка захвата mutex-ов.

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

Было найдено вот такое решение:

#if defined( __SANITIZE_THREAD__ )

template< typename M >
class tsan_friendly_lock_guard
{
   M & m_what;

public:
   tsan_friendly_lock_guard( M & what )
      : m_what{ what }
   {
      while( !m_what.try_lock() )
      {
         std::this_thread::yield();
      }
   }

   ~tsan_friendly_lock_guard()
   {
      m_what.unlock();
   }
};

#else

template< typename M >
class tsan_friendly_lock_guard
   {
      std::lock_guard< M > m_guard;

   public:
      tsan_friendly_lock_guard( M & mutex )
         : m_guard{ mutex }
         {}
   };

#endif

Затем в тех местах кода, где TSan ругался на потенциальную инверсию порядка захвата mutex-ов, std::lock_guard был заменен на tsan_friendly_lock_guard. И оно сработало: https://godbolt.org/z/fb84zsr4M.

[prog.c++.multithreading] Теперь уж точно false positive в thread sanitizer-е

2026-07-16T09:06:17.685+03:00

Следом за предыдущей, нашел еще одну неприятную ситуацию с thread sanitizer. Но теперь это на 100% ложно позитивное срабатывание.

Посмотреть можно на godbolt: https://godbolt.org/z/zfGfhq89d

Суть в том, что в одной нити захватывается сперва mutex у child-а, а затем, при все еще захваченном mutex-е child-а, захватывается mutex у parent-а.

А потом, когда все ранее захваченные mutex-ы освобождены, уже на другой нити сперва захватывается mutex у parent-а, а следом, не отпуская mutex parent-а, захватывается mutex у child-а.

Thread sanitizer выдает предупреждение о потенциальном дедлоке из-за инверсии порядка захвата мутексов.

Только вот здесь эта инверсия невозможна в принципе, т.к. сперва гарантированно заканчиваются все операции с child-ом, и лишь затем стартует нить, на которой делаются манипуляции с parent-ом.

И вот как удовлетворить thread sanitizer, чтобы он в данном месте не выдавал свою диагностику... Это пока для меня большой вопрос.

Upd. Похоже, это уже известная проблема. С 2022-го года.

Upd2. Найденный обходной маневр: вспомогательный класс tsan_friendly_lock_guard.

#include <thread>
#include <mutex>

struct info
{
   std::mutex m_lock;

   info * m_parent{ nullptr };
   info * m_child{ nullptr };

   void
   activate( info * parent )
   {
      std::lock_guard< std::mutex > lock{ m_lock };

      m_parent = parent;

      m_parent->add_child( this );
   }

   void
   deactivate()
   {
      std::lock_guard< std::mutex > lock{ m_lock };

      if( m_child )
         m_child->deactivate();
   }

   void
   add_child( info * child )
   {
      std::lock_guard< std::mutex > lock{ m_lock };

      m_child = child;
   }
};

int main()
{
   info parent, child;

   child.activate( &parent );

   std::thread parallel_task{ [&parent] { parent.deactivate(); } };
   parallel_task.join();
}

[prog.c++.multithreading] Интересно, это false positive от thread sanitizer-а или нет?

2026-07-15T15:40:20.303+03:00

Примечание: первоначальный вариант этого поста описывал мое ошибочное предположение о том, что thread sanitizer выдал ложное срабатывание. Однако, ув.тов.Николай Меркин (кому-то он известен как Кодт с RSDN) указал на реальную ошибку. Поэтому текст был переработан.

Thread sanitizer выдал предупреждение на код, который я много лет считал корректным.

Для нетерпеливых вот самодостаточный пример на godbolt: https://godbolt.org/z/3xPadcnva.

Для всех остальных пояснение:

на главной нити создается объект actual_repo. В этом объекте живут и std::mutex, и condition_variable (на котором будет осуществляться ожидание);
ссылка на actual_repo передается в дочернюю нить. Через какое-то время дочерняя нить вызывает для actual_repo метод stop;
главная же нить засыпает на вызове wait_for_stop у объекта actual_repo. Этот метод вернет управление только после того, как дочерняя нить вызовет stop;
когда дочерняя нить вызывает stop, то главная нить просыпается, выходит из wait_for_stop, после чего разрушается объект actual_repo;
после чего дожидаемся завершения дочерней нити и прекращаем работу.

Фокус здесь в том, что внутри stop условная переменная взводится (вызов notify_one()) без захвата мутекса.

А это ведет к тому, что главная нить может проснуться и уничтожить объект actual_repo еще до того, как дочерняя нить завершит вызов stop.

Т.е. деструктор для repo_basic::m_stop_initiated_cv может отработать еще до того, как на дочерней нити завершится вызов m_stop_initiated_cv.notify_one().

И как раз thread sanitizer и ругается на то, что в главной нити происходит модификация содержимого repo_basic::m_stop_initiated_cv тогда как на дочерней нити мы это содержимое только только прочитали.

Проблема же оказалась в том, что метод stop, вызванный на дочерней нити, не является атомарным. В нем сперва вызывается try_initiate_stop из базового класса. В этом самом try_initiate_stop захватывается mutex, меняется значение m_status, после чего mutex освобождается. Управление возвращается в метод stop и только после этого взводится m_stop_initiated_cv.

Именно эта неатомарность и является корнем зла.

Главная нить в методе wait_for_stop может захватить mutex и проверить m_status как раз в момент, когда на дочерней нити завершился try_initiate_stop, но еще не было обращения к m_stop_initiated_cv. И если такое произойдет, то главная нить уничтожит объект actual_repo еще до того, как на дочерней нити произойдет вызов m_stop_initiated_cv.notify_one().

А это приведет к тому, что notify_one() будет вызываться уже для убитого объекта.

Полагаю, на именно на эту проблему мне и указывал thread sanitizer, но я не смог с первого раза разобраться что же идет не так.

Так что в данном случае thread sanitizer выявил реальную проблему.

#include <thread>
#include <mutex>
#include <condition_variable>
#include <chrono>
#include <iostream>

class repo_basic
{
protected:
   std::mutex m_lock;
   std::condition_variable m_stop_initiated_cv;

   int m_status{ 0 };

   int
   try_initiate_stop()
   {
      std::lock_guard< std::mutex > lock{ m_lock };

      if( !m_status )
      {
         m_status = 1;
         return m_status;
      }

      return -1;
   }

public:
   void
   wait_for_stop()
   {
      std::unique_lock< std::mutex > lock{ m_lock };

      m_stop_initiated_cv.wait( lock,
            [this]{ return 0 != m_status; } );
   }
};

class actual_repo : protected repo_basic
{
public:
   using repo_basic::wait_for_stop;

   void
   stop()
   {
      const auto r = this->try_initiate_stop();
      if( 1 == r )
      {
         this->m_stop_initiated_cv.notify_one();
      }
   }
};

int main()
{
   std::thread child_task;

   {
      actual_repo repo;
      child_task = std::thread{
            [&repo]()
            {
               // Take some time to the main thread to call wait_for_stop.
               std::this_thread::sleep_for( std::chrono::milliseconds{ 250 } );
               repo.stop();
            }
         };

      repo.wait_for_stop();
   }

   child_task.join();

   std::cout << "successful completion" << std::endl;
}

[prog.eiffel] Сохраню в склерозник пример работы с anchored-типами в Eiffel

2026-07-03T11:07:53.385+03:00

Есть очень прикольный язык программирования -- Eiffel. А в нем есть очень прикольная фича -- заякоренные типы (anchored types). Давеча пришлось в одном из разговоров про нее вспомнить и набросать небольшой пример, чтобы проверить те или иные предположения.

У Eiffel-я есть он-лайн компилятор (что-то по типу godbolt, wandbox, ideone), но в нем нельзя просто так сохранить сделанное и поделиться публичной ссылкой. Поэтому помещу под кат код написанного примера, просто на память, а то вдруг еще раз потребуется.

В чем суть примера?

Есть базовый класс MESSAGE.

Есть базовый класс ENVELOPE, который хранит в себе MESSAGE. Но класс ENVELOPE написан с использованием MESSAGE в качестве якорного типа. Что позволяет создать наследника SIGNED_ENVELOPE, который хранит уже не просто MESSAGE, а SIGNED_MESSAGE. Но менять унаследованные из ENVELOPE методы не нужно, Eiffel сам разбирается с тем, что в SIGNED_ENVELOPE методы make и change_content получают уже не MESSAGE, а SIGNED_MESSAGE.

При этом Eiffel что-то может проверить в compile-time. Например, если у нас есть ссылка signed_env с типом SIGNED_ENVELOPE, то в вызов signed_env.change_content мы не может отдать просто ссылку на MESSAGE. Будет ошибка компиляции, компилятор ждет от нас SIGNED_MESSAGE (или наследника SIGNED_MESSAGE).

Но если у нас есть env типа ENVELOPE и мы env присвоили signed_env (т.е. теперь env ссылается на экземпляр SIGNED_ENVELOPE), то компилятор пропустит передачу обычного MESSAGE в env.change_content. Но ошибка будет диагностирована в run-time с выбросом исключения. Т.е. "обмануть" Eiffel не получится: то, что Eiffel не смог поймать в compile-time, он поймает в run-time.

Особенностью Eiffel-я является то, что каждый класс должен помещаться в отдельном файле. Поэтому сколько классов, столько и файлов.

Файл application.e

class
    APPLICATION

inherit
    ARGUMENTS_32

create
    make

feature {NONE} -- Initialization

    make
            -- Run application.
        local
            env: ENVELOPE
            env2: SIGNED_ENVELOPE
            msg: MESSAGE
        do
            create env.make (create {MESSAGE}.make("Hello"))
            env.examine_content

            create env2.make (create {SIGNED_MESSAGE}.make("Bye"))
            env2.examine_content

            env := env2
            msg := create {SIGNED_MESSAGE}.make("222")
            env.change_content (msg)
            env.examine_content
        end

end

Файл msg.e

class
    MESSAGE

create
    make

feature
    body: STRING

    make(b: STRING)
        do
            body := b
        end

feature
    tell_about_itself
        do
            print("Message body is '")
            print(body)
            print("'%N")
        end
end

Файл envelope.e

class
    ENVELOPE

create
    make

feature
    msg: MESSAGE

feature
    make (m: like msg)
        do
            msg := m
        end

    change_content (m: like msg)
        do
            msg := m
        end

    examine_content
        do
            msg.tell_about_itself
        end
end

Файл signed_msg.e

class
    SIGNED_MESSAGE

inherit
    MESSAGE
        redefine
            tell_about_itself
        end

create
    make

feature
    tell_about_itself
        do
            print("SIGNED message body is '")
            print(body)
            print("'%N")
        end
end

Файл signed_envelope.e

class
    SIGNED_ENVELOPE

inherit
    ENVELOPE
        redefine
            msg
        end

create
    make

feature
    msg: SIGNED_MESSAGE

end

[life.cinema] Очередной кинообзор (2026/06)

2026-07-01T08:49:21.601+03:00

Традиционный обзор отсмотренных фильмов. Традиционно в начале каждого из списков идет то, что понравилось больше, а в конце то, что понравилось меньше.

Фильмы

Грязные деньги (In The Grey, 2026). Тупо, прямолинейно, приторно красиво, но бодренько. За неимением лучшего можно посмотреть, чтобы скоротать вечер.

Мандалорец и Грогу (The Mandalorian and Grogu, 2026). Отличная сказочка для семейного просмотра с детьми младшего школьного возраста. Разве что немного мрачноватая. В любом случае кино абсолютно детское, взрослым к нему всерьез относиться не стоит.

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

Ограбить Лондон (Fuze, 2025). Ничего не ждал от фильма вообще, думал обычная третьесортная поделка. Оказалось на удивление хорошо. Т.е. это далеко не шедевр, уровнем чуть повыше среднего, но на фоне всего остального шлака, прям глоток свежего воздуха.

Охота за тенью (Shadow's Edge, 2025). Очень бодрая сказочка. Джеки Чану мое почтение.

Мусорщик (Wasteman, 2025). Мне показалось, что это неплохая тюремная драма. Но, во-первых, понятия не имею насколько это достоверно. И, во-вторых, смотрел на скорости 1.25, потому что на нормальной скорости было ну как-то совсем уж нудно. Тем не менее, развязка понравилась.

Сериалы

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

Заложник (первый сезон, 2026). Начало бодрое, затем все скатилось в какую-то сопливую Санта-Барбару. При этом сериальная затянутость ощущается даже не смотря на то, что в сезоне всего шесть серий. Ну и отдельно не понравилось то, что повествование оборвали на полуслове с явным намерением продолжить в следующем сезоне. Снято, однако, качественно. К картинке претензий нет.

Бухта вдов (Widow's Bay, первый сезон, 2026). Скучно, что-то реально интересное и удивляющее происходит очень редко. Сама история толком ничем не закончилась, тут нам явно предлагают ждать следующих сезонов. Купился на хвалебные отзывы в Интернете, по итогу не понравилось, жаль потраченного времени.

Красота (The Beauty, первый сезон, 2026). Первые серии хорошие -- тут и экшен, и драйв, и многообещающая завязка. Затем темп повествования потерялся, драйв улетучился. Финала как такового у первого сезона нет. Создатели обрывают происходящее буквально на полуслове. Возможно, когда выйдет второй сезон, и история достойным образом разовьется, то этот сериал можно будет хоть как-то оценить. Но не в его текущем виде.

Не смог досмотреть

Опасные отношения (Over Your Dead Body, 2026). Это ремейк фильма Поездка (I onde dager, 2021). И, как по мне, так оригинал смотреть интереснее, в нем как-то все более естественно.

Дьявол носит Prada 2 (The Devil Wears Prada 2, 2026). Происходящее на экране невозможно воспринимать серьезно.

Вне категории

Ангелы Ладоги (2026). Такое впечатление, что фильм рассчитан совсем на другое поколение. Возможно, на современных детей 8-10 лет. Как мне его оценивать непонятно.

Литвяк (2026). С одной стороны, хороший военный фильм, без пьяных командиров, трусливых комиссаров и неадекватных СМЕРШев с наганами в руках. С другой стороны, рассказанная история нисколько не зацепила, главные герои показаны так, что не успеваешь к ним прикипеть так, чтобы их гибель заставляла тебя переживать именно потому, что ты успел проникнуться к ним какими-то чувствами. Кроме того, напрягает и раздражает то, насколько много сцен в фильме снято на фоне зеленого экрана. В общем, не знаю, как оценивать. За попытку снять хороший фильм о войне -- отлично, за исполнение -- незачет 🙁

[prog.thoughts] Начинаю думать, что бесстековые короутины в C++ следовало делать чуть иначе

2026-06-29T06:47:28.424+03:00

Прежде чем перейти к заявленной в заголовке теме небольшое погружение в контекст. Появились небольшие ресурсы для того, чтобы попробовать добавить в SObjectizer поддержку бесстековых короутин из C++20.

Изначально я планировать только позволить пользователю описывать event-handler-ы, в которых можно было бы делать co_await. Но по мере продумывания способов реализации столкнулся с тем, что не имею на руках никаких механизмов запуска внешних по отношению к SO-5 короутин. А это нужно, чтобы проверить, что из event-handler-а можно дернуть, скажем, короутину из Asio, и когда она завершится, управление должным образом вернется event-handler-у.

И тогда появилась мысль сделать сперва возможность асинхронной работы с mchain-ами. Сейчас в SO-5 есть синхронные версии receive и select, а что, если предоставить их асинхронные версии? Тогда в event-handler-е можно было бы написать что-то вроде:

so_5::event_handler_task_t
some_agent::evt_some_handler( mhood_t<some_msg> cmd )
{
auto result = co_await so_5::async_receive( so_5::from( test_chain ), ... );
...
}

Тогда отправляя (или не отправляя) сообщения в тестовый канал я бы мог тестировать поведение event-handler-ов.

Но стоило погрузиться в задачу создания асинхронных версий async_receive и async_select-а, как стало возникать подспудное подозрение, что с C++ными бесстековыми короутинами что-то не так. И я не говорю про их мудреность (это тема отдельного разговора). Было ощущение, что несмотря на заумность и гибкость C++ных короутин в них все-таки чего-то важного не хватает.

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

Суть в том, что в интерфейсе короутин нет способов явно указать на каком рабочем контексте короутина должна быть продолжено. Лично мне не очевидно кто и где будет вызывать resume для coroutine_handle когда короутина окажется готова к возобновлению.

Видимо, авторы короутин в C++20 предполагали, что когда короутины применяются в рамках одного фремворка, где все короутины обслуживаются одним и тем же механизмом, такой проблемы нет в принципе. Однако, если возникает необходимость подружить сразу несколько разных реализаций короутин, вот тогда эта проблема встает в полный рост.

В Capy ее предлагают решать за счет введения специальной сущности -- Executor-а и за счет изменения интерфейса сущности Awaiter-а: метод await_suspend для Awaiter-а вместо одного аргумента получает два:

std::coroutine_handle<> await_suspend(std::coroutine_handle<> h, io_env const* env);

И во втором параметре передаются вещи, которые могут потребоваться короутине (и ее дочерним короутинам): executor, stop_token, allocator.

За счет того, что в env есть ссылка на executor, короутина может сохранить этот executor и, когда возникает возможность возобновить работу, короутина обращается к этому executor-е с просьбой обеспечить это возобновление на должном контексте.

Это как раз то, чего мне не хватало для реализации асинхронных версий receive/select. Я уже сам пришел к мысли о том, что в асинхронный receive нужно передавать какой-то coro_scheduler, который будет отвечать за то, чтобы возобновить приостановленный receive/select именно там, где это разрешено. Например, если receive вызывается из event-handler-а, то это могло бы выглядеть так:

auto result = co_await so_5::receive(
so_5::from( test_ch ).resume_by( this->so_coro_scheduler_for_this_agent() )...,
... );

А если mchain используется вне агентов, то может быть что-то вроде:

so_5::cpp_coro::this_thread_scheduler_t coro_scheduler;
coro_scheduler.sync_wait(
  [&coro_scheduler, &ch]() -> so_5::cpp_coro::async_receive_task_t {
    co_await so_5::receive(
      so_5::from( ch ).resume_by( coro_scheduler )..., ...);
  } );

И каково же было мое удивление, когда знакомясь с библиотекой Capy увидел, что ее авторы тоже пришли к явной передаче executor-а.

Но, повторюсь, и подход Capy, и мои попытки придумать некий условный coro_scheduler для SObjectizer-а -- это попытки прикрутить решение сбоку посредством синей изоленты.

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

Например, чтобы обращение к co_await можно было параметризовать. Скажем, передавать executor/scheduler непосредственно в co_await:

co_await(executor) some_task();

И чтобы этот executor передавался бы параметром в await_resume. Может быть в виде ссылки на некоторый специальный объект environment, как это делается в Capy.

Есть у меня подозрение, что с такой явной передачей executor-ов в co_await, код с короутинами и писать, и читать было бы гораздо проще.

PS. Раз уж заговорил про попытку добавить поддержку короутин в SO-5, то слегка обозначу текущий статус. Пока до чего-то работающего еще далеко. Пытаюсь двигаться от простого к более сложному. Сперва хочу попробовать сделать асинхронную версию receive/select. Чтобы с ее помощью перейти к поддержке event-handler-ов в виде короутин. Затем, возможно, попробую погрузиться еще глубже, чтобы разрешить короутины в роли обработчиков входящих сообщений в receive/select (если это вообще возможно). Работы много, ресурсов мало, движется все очень медленно. Поэтому я сам в течении ближайших пару месяцев никаких значимых результатов не жду.

[prog.c++.imho] Не согласен с постулатами пропозала P3097 (контракты для виртуальных методов)

2026-06-15T10:23:37.893+03:00

Комитет по стандартизации C++ продолжает творить дичь. Сперва в C++26 были включены кастрированные контракты (нет ключевого слова old в постусловиях, нет контрактов для виртуальных методов, нет инвариантов для экземпляров классов и циклов). Для людей, знакомых с Eiffel, контракты из C++26 выглядят как "мы не осилили тему полностью, поэтому впихнули в стандарт какой-то эрзац с надеждой, что со временем допилим". Не хочу обсуждать зачем нужен эрзац вместо нормального продукта. Просто перейду к следующей дичи.

Далее в C++29 включили предложение P3097, которое описывает контракты для виртуальных методов классов. И авторы этого предложения, как по мне, покусились на святое: на сформулированное много-много лет назад для Design By Contract в Eiffel-е требование о том, что производный класс может только ослабить предусловния и ужесточить постусловия, но не наоборот.

И вот авторы пропозала почему-то пришли к выводу, что C++ настолько особенный, что в нем можно это требование послать в пешее эротическое.

На протяжении нескольких страниц пропозала эти люди пытаются приводить "аргументацию" своей точки зрения. Меня эта аргументация не убеждает от слова совсем. Скорее наводит на мысль о том, что люди толком не понимают тему, о которой пытаются рассуждать и, скорее всего, не имеют опыта разработки на языках с поддержкой Design By Contract (в первую очередь на Eiffel-е, на который в данной теме и следует равняться).

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

В разделе "3.2 Adoptability in legacy code" есть интересный заход:

In other words, contract assertions must not break an existing program. While false negatives are inevitable, false positives must never be forced on users by the language design.

These requirements are not unique to contract checking; they apply equally to any tool intended to detect bugs in existing code, such as compiler warnings or static analysis tools.

Мне он кажется в принципе не правильным.

Во-первых, если мы внедряем механизм, который позволяет выявлять проблемы в коде (а DbC выявляет проблемы на уровне проектирования классов, их взаимосвязей и взаимодействия), то это хорошо. Это цель внедряемого механизма. Поэтому если мы с помощью контрактов формально зафиксировали ожидания, которые ранее были неформальными, и у нас что-то поломалось, значит контракты нашли проблему о которой мы и не подозревали. Следовательно, проблема требует решения (либо в виде переделки кода, либо в переформулировании контрактов).

Во-вторых, а почему бы не применить эту формулировку к такой штуке, как standard library hardening, которую также внедрили в C++26. У нас же теперь обращения к operator[] для std::span будут проверять индекс. И допустим, у нас был код:

unsigned long check_sum(const std::span<const char> & s)
{
   unsigned long sum = 0;
   for(std::size_t i = 0; i <= s.size(); ++i)
       sum += static_cast<unsigned char>(s[i]);
   return sum;
}
const std::string s{ "Hello, world" };
const char * l = "Hello, world";
auto ch1 = check_sum(s);
auto ch2 = check_sum(l);

Этот код работал годами поскольку в позиции s[s.size()] хранится неявно добавляемый к содержимому строки 0-символ. Мы совершали ошибку индексации, но нам это прощалось из-за особенностей представления содержимого нуль-терминированной строки и из-за того, что лишнее нулевое значение не влияет на данный алгоритм, а в std::span не было проверки границ для operator[]

Но в режиме hardening мы здесь получим исключение (или вообще принудительную терминацию программы). А ведь это же тот самый "breaking an existing program" которого следует избегать. Но для standard library hardening мы на breaking смело идем, а вот в случае с контрактами почему-то идти не должны. В воздухе отчетливо ощущается запах двойных стандартов.

Как по мне, так при внедрении некоторых фич в принципе нельзя оглядываться на легаси код. Вспомнить хотя бы всратые модули, добавленные в C++20. Так почему при внедрении контрактов нужно апеллировать к коду, в котором контрактов нет?

В разделе "4.8 Narrowing preconditions, widening postconditions" приводится пример на котором авторы P3097 пытаются оправдать своей тезис о том, что в мире С++ нужно отойти от "ослабить предусловия, ужесточить постусловия" в пользу "ужесточить предусловия, ослабить постусловия".

Типа есть класс:

class Image {
public:
virtual void render() const;
};

и есть его наследник:

class GPUImage : public Image {
   bool readyToRender = false;
public:
   bool prepare() {
      // upload data to GPU, handle errors…
      readyToRender = true;
      return readyToRender;
   }

   void render() const override
      pre (readyToRender);
};

В классе наследнике предусловие для метода render ужесточается. Авторы пропозала считают этот пример нормальным и используют его в качества аргумента в пользу постулата, что в С++ нам нужно иметь возможность "ужесточать предусловия, ослаблять постусловия".

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

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

В данном конкретном примере класс GPUImage вообще не должен быть наследником Image (по крайней мере публичным). И возможное решение описанной "проблемы" не в изменении контракта, а в другой реализации GPUImage. Например, вот в такой:

class GPUImage {
   class ActualImage : public Image {...};
   std::optional<ActualImage> actualImage; // Will be initialized in prepare.
public:
   bool prepare() {
      actualImage.emplace(...); // upload data to GPU, handle errors…
      return true;
   }

   Image & getActualImage()
      pre (actualImage.has_value())
   {
      return *actualImage;
   }
};

В этом случае мы не можем отдать экземпляр GPUImage туда, где ждут Image, поскольку GPUImage не выполняет требования контракта. Но мы можем вызвать GPUImage.getActualImage(), чтобы получить актуальную реализацию интерфейса Image.

И вот уже к getActualImage() мы можем применить любой контракт, в том числе и тот, что getActualImage() может вызываться только после того, как будет вызван prepare().

В разделе "4.9 Multiple inheritance" приводится пример с классами EvenComputer и OddComputer:

struct EvenComputer {
  virtual int compute(int x)
    pre(isEven(x))
    post(r : isEven(r));
};

struct OddComputer {
  virtual int compute(int x)
    pre(isOdd(x))
    post(r : isOdd(r));
};

Мол если мы отнаследуемся от обоих классов сразу и сделаем общий compute, то у нас будет нарушение контрактов из базовых классов. Поэтому нужно уметь отменять унаследованные контракты, по типу:

struct Identity : EvenComputer, OddComputer {
int compute(int x) override { return x; }
};

Как по мне так это пример ущербности поддержки множественного наследования в C++, а не признак необходимости нарушить правило "ослабление предусловий, ужесточение постусловий".

В Eiffel, как в языке, где к проблемам наследования отнеслись более тщательно, чем в C++ (т.е. подумали, а не сделали "как получилось"), есть возможность переименования в производном классе метода из базового класса. А в C++, увы, такой возможности нет. Поэтому в C++ мы имеем то безобразие, которое видно в этой самой структуре Identity.

Будь в C++ гипотетическая конструкция rename, то данный пример можно было бы переписать так:

struct Identity : EvenComputer, OddComputer {
  rename EvenComputer::compute as even_compute;
  rename OddComputer::compute as odd_compute;

  // Это уже метод Identity, а не переопределение унаследованных
  // методов compute.
  int compute(int x) { return x; }

private:
  // А вот это уже переопределение.
  int even_compute(int x) override { return this->compute(x); }
  int odd_compute(int x) override { return this->compute(x); }
};

В этом случае для каждого унаследованного метода compute контракты из базового типа сохранились бы. Только контракт EvenComputer::compute теперь применяется не к Identity::compute, а к Identity::even_compute. И вот в таком случае:

void use_computer(EvenCompute & c) { c.compute(0); }

Identity my_computer;
use_computer(my_computer);

Внутри use_computer вызывался бы метод Identity::even_compute.

Лично мне в C++ такого rename не хватает и без контрактов. И если бы rename в язык ввели, то это бы помогло и контрактам, и не только.

Поэтому в данном конкретном случае авторы P3097 увидели лишь часть проблемы, неверно ее идентифицировали и, соответственно, стали решать неправильно. Дело не в контрактах, а в ущербности множественного наследования в C++. А бороться с этой ущербностью посредством каких-то специальных контрактов, придуманных под якобы "особенности C++", это очень и очень странный подход, как по мне.

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

Общее впечатление: у авторов пропозала нет достаточного опыта работы с языками с поддержкой Design By Contract. И, в первую очередь, с Eiffel. А без такого опыта рассуждения о якобы проблемах DbC и уникальности C++ -- это как из анекдота про "Рабинович напел".

Поэтому я категорически не согласен с тем, что от принципа "ослаблять предусловия, ужесточать постусловия" нужно отказываться. Тем более в сторону "ужесточать предусловия, ослаблять постусловия". Это выглядит как переворачивание DbC с ног на голову.

Не надо так. Не нужно окончательно превращать C++ в помойку из переусложненных концепций (хватит нам короутин, модулей и экзекуторов). Есть опыт Eiffel, уже почти сорокалетний(!!!), но... Но даже так вы сделать не можете (если думаете, что можете, посмотрите еще раз на то, что есть в Eiffel и то, что "есть" в С++26). Однако умничаете и изобретаете велосипед с квадратными колесами вместо того, чтобы научиться ездить на обычном.

Фокус с контрактами в том, что это такая же фича в распоряжении разработчика, как наследование, исключения и noexcept, перегрузка функций и операторов. Это значит, что контрактами нужно научиться пользоваться точно так же, как и другими возможностями языка. Что с контрактами точно так же будет и перебор (когда контракты делают слишком жесткими и пихают куда ни попадя), и недостаточное использование (когда от контрактов отказываются по надуманным причинам). А это значит, что разработчики будут совершать ошибки, эти ошибки затем придется устранять и это нормальный процесс. Такой же нормальный, как, например, впихивание noexcept куда ни попадя с последующим пересмотром и отказом от части noexcept.

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

Посему не нужно изобретать велосипед с квадратными колесами только потому, что вам C++ кажется каким-то особенным языком, в котором почему-то не работает то, что работает в Eiffel. Вам, скорее всего, кажется. Но из-за того, что вы свои заблуждения протолкнули в стандарт, с этим теперь придется жить нам всем, даже тем, кто не разделяет вашей убежденности. Как с модулями, которые тоже кому-то казались хорошей идеей. Или как со спецификатором throw в C++98.

[prog.c++] Похоже, что SObjectizer-5 будет использоваться в еще одном проекте

2026-06-12T17:51:46.788+03:00

Больше двух лет сотрудничаю с интересным проектом. Занимался в рамках этого проекта разными задачами, начинал вообще с замены C++ REST SDK на RESTinio, а потом пошло поехало по нарастанию сложности 😎. Не все из этого было связано с многопоточностью, но многое.

Многопоточность здесь самая обычная -- std::thread, std::mutex, std::condition_variable, немного std::atomic-ов. Ну и специфика больше про параллельную обработку данных, нежели про событийно-ориентированное программирование.

Местами об отсутствии SO-5 в проекте приходилось жалеть, но, по большому счету, всерьез только один раз. Мне кажется, что та задачка на агентах решалась бы проще, чем на std::thread. Плюс еще пара-тройка мест, где простой агент с периодическим сообщением, на мой взгляд, оказался бы практичнее, чем выделенная нить с ручным циклом вокруг std::this_thread::sleep_for. Т.е. в недавнем прошлом от SO-5 полезный выхлоп вряд ли был заметным.

Однако, не так давно в проекте появился фрагмент, сделанный на базе отличной (тут я совершенно серьезно) маленькой библиотеки Taskflow. Этот кусочек касался координации параллельной обработки информации. Представьте себе, что у вас в памяти несколько связанных таблиц и нужно собрать суммы некоторых столбцов этих таблиц. При этом если в какой-то ячейке одной таблицы стоит ссылка на регион другой таблицы, то в качестве значения ячейки нужно взять сумму этого региона. А если в этом регионе есть ссылки на регионы других таблиц, то процедуру нужно повторить рекурсивно.

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

Такое распараллеливание средствами Taskflow было сделано, но некоторый осадочек остался:

в Taskflow нет встроенной поддержки таймеров. Одна из идей о том как оптимальнее поделить общий объем работы на отдельные кусочки базировалась на том, чтобы контролировать процесс через некоторые интервалы времени. Типа начнем считать на текущем треде, но поставим отложенную на 250ms задачу. Если к моменту ее запуска вычисление не завершится, то задача возьмет на себя часть оставшейся работы. Если же вычисление успеет закончится, то надобность в отложенной задаче отпадет. Только вот провалидировать эту идею из-за отсутствия таймеров в Taskflow сходу не получилось;
не был понятно как в Taskflow реализовать квотирование имеющихся ресурсов для того, чтобы одно вычисление не захватило все ресурсы себе, а оставшиеся вычисления сидели бы на "голодном пайке". При этом на горизонте маячит фича по приоритетам вычислений, т.е. каким-то высокоприоритеным вычислениям такая узурпация ресурсов разрешается, а вот низкоприоритетным -- нет.

Возможно, все это можно было бы сделать и средствами Taskflow, если в достаточной степени изучить ее возможности и детали реализации. Но попутно стали всплывать и другие моменты.

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

Или, к примеру, запускается какая-то длительная операция (например, выгрузка части данных на диск). Сейчас для этой операции стартует отдельный тред, на котором операция выполняется, после чего тред завершается. Но плохо то, что таких тредов в какой-то момент может стать слишком много. Лучше бы их как-то координировать. И тут кажется, что сделать такого координатора на базе одного агента-менеджера и нескольких агентов-исполнителей несколько проще, чем посредством некой общей структуры данных, защищенной mutex-ом.

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

Не знаю, приживется ли SO-5 в проекте окончательно. Развитие идет динамично и у команды очень легкое отношение к включению или изъятию тех или иных зависимостей. Это я с большой осторожностью отношусь к тому что включать, а что нет, и могу долго раздумывать над тем, можно ли обойтись без какой-нибудь внешней библиотеки. Но здесь ребята более шустрые и рисковые -- если подвернулось что-то потенциально полезное, то сходу добавили. Если не оправдало себя, то не менее быстро выбросили 🙂

Так что может быть и SO-5 через месяц-другой-третий постигнет участь Taskflow. Поживем -- увидим. Сам я к этому отношусь спокойно: будет в проекте SO-5 -- хорошо, не будет -- не страшно. Даже если в итоге от SO-5 откажутся, то это даст еще больше полезной информации о том, где SO-5 применим, а где не очень.

Пока же я рад происходящему и есть два воодушевляющих фактора:

Во-первых, появляется дополнительный стимул изыскать время и ресурсы, чтобы возобновить дальнейшую работу над SObjectizer-ом. Признаюсь честно, что в последние 3-4 месяца с этим были проблемы, не хватало мне сил после основной работы находить еще по 2-3 часа в день, чтобы, скажем, вернуться к поддержке короутин в SO-5.

Во-вторых, SO-5 будут изучать и пробовать в работе совершенно новые люди. Наверняка от них последуют какие-то замечания/соображения, которые позволят сделать SObjectizer еще лучше. Да и вообще опыт применения SO-5 в новом проекте лишним точно не будет.

Так что будем пробовать и смотреть что из этого получится.

[life.audiophilia.diy] Попробовал давеча 10mm динамики в наушниках-затычках. На свою голову...

2026-06-08T08:51:00.083+03:00

Поскольку в области 15.4mm и 14.8mm динамиков для наушников-вкладышей перепробовал уже практически все, что заслуживало внимания, то решился на эксперимент с 10mm динамиками для внутриканальных наушников. Но т.к. заушные мониторы мне не подходят, то остановился на форм-факторе "затычек".

Взял вот эти недорогие (по меркам 10mm динамиков) драйверы:

И установил их вот в такие корпуса (из черного дерева):

Немного помучался с подбором амбушюр...

Но результат получил такой, что даже и не знаю как охарактеризовать.

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

Но даже если не брать особенности НЧ, то и на всех остальных диапазонах сплошные кардинальные улучшения. Все гораздо более отчетливее. Плюс гораздо большая "глубина" сцены.

В общем, в затычках как будто бы выходишь на совершенно другой уровень.

Однако, есть подозрение, что все это далеко не бесплатно для ушей. Чтобы все эти прелести воспринимать мне нужны амбушюры размера L. И хоть я и выбрал самые мягкие из имеющихся, но все равно ощущение, что вставляешь толстые палки в слуховые каналы. Это ощущение практически исчезает минут через 7-10 после начала прослушивания, хотя того комфорта, который есть со вкладышами, когда "вставил и забыл", нет и близко. Поэтому когда наушники извлекаешь, то чувствуешь пусть и небольшое, но физическое облегчение. А такой дискомфорт, хоть он и не сильный, вряд ли полезен для слуха.

Так что очень стремно своими новыми затычками пользоваться. Как бы потом не пришлось расплачиваться за хороший звук проблемами с перепонками из-за усиленного образования ушной серы.

[prog.c++] Попробовал познакомиться с модулями C++20 и чего-то недопонял

2026-06-01T14:06:18.491+03:00

Провел пару простых экспериментов с модулями C++20 и получил странные результаты.

Эксперименты проводились под Windows с VS2022 и VS2026 (обновления от мая 2026-го) и ArchLinux с GCC 16.1 и clang 22.1.

Ожидаемые мной результаты (т.е. отсутствие проблем компиляции/линковки) получились только с clang 22.1 и libc++. А вот с GCC и VC++ случились какие-то проблемы, которые мне сложно объяснить.

Во всех случаях сборка осуществлялась через CMake и Ninja.

Исходные коды описанных ниже тестовых программ можно найти в этом репозитории.

Эксперимент первый (case_001 из упомянутого репозитория). Очень простой модуль. Декларация в файле hello.ixx:

module;

#include <iostream>
#include <typeinfo>

export module hello;

export namespace hello
{

void greet();

template<typename T>
struct helper
{
   static void
   a();

   static void
   b();
};

template<typename T>
void
helper<T>::a()
{
   std::cout << "helper<" << typeid(T).name() << ">::a()" << std::endl;
}

template<typename T>
void
helper<T>::b()
{
   std::cout << "helper<" << typeid(T).name() << ">::a()" << std::endl;
}

} // export namespace hello

Реализация в файле hello.cpp:

module;

#include <iostream>

module hello;

namespace hello
{

void greet()
{
std::cout << "hello, world!" << std::endl;
}

} /* namespace hello */

Но мне кажется, что ключевой момент в том, что шаблон класса helper реализован прямо в hello.ixx.

Описание библиотеки hello для CMake:

cmake_minimum_required(VERSION 3.28)
project(hello CXX)

set(CMAKE_CXX_EXTENSIONS OFF)
set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED YES)

add_library(hello)

target_sources(hello
   PUBLIC
      FILE_SET CXX_MODULES FILES
         hello.ixx
   PRIVATE
      hello.cxx
)

Используется это в очень простой программе:

import hello;

int main()
{
   hello::greet();

   hello::helper<int>::a();
   hello::helper<long>::b();
}

И здесь засада №1. В clang-е все OK, как я и ожидаю.

А вот для GCC и MSVC++ ошибка компиляции -- оказывается, в методах helper::a и helper::b не определен символ type_info.

Решается эта проблема добавлением в тестовую программу `#include <typeinfo>` для MSVC++. Тогда как для GCC нужен еще и `#include <iostream>`

Но здесь я перестаю понимать суть модулей. Ведь типа модуль -- это самодостаточная сущность. Если в модуле был сделан нужный набор include-ов, то в месте, где импортированный из модуля метод/класс/функция используется, уже никаких дополнительных include не нужно.

Такое ощущение, что GCC/VC++ для шаблонов в модуле просто сохраняют какое-то частично разобранное представление, которое просто 1-в-1 переносят в место использования шаблона и окончательный парсинг/анализ делают уже только в месте инстанцирования. Поэтому т.к. в тестовой программе не подключения заголовочного файла typeinfo, то нет и определения символа type_info.

Тогда как clang делает более глубокий и честный разбор тела шаблона и с символом type_info он определяется уже при компиляции самого модуля (либо же он умудряется дополнять код тестовой программы нужными include-ами автоматически -- типа того, что если в определении модуля использовался `#include <typeinfo>`, то этот же include нужно неявно подставить и в то место, где совершен импорта модуля).

Случай второй (case_003 из упомянутого выше репозитория).

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

На простых .hpp-файлах это работает без проблем. А вот как сделать подобное на модулях?

После некоторого выкуривания бамбука пришло такое "решение".

Есть отдельный module partition unit (не знаю как лучше данный термин на русский язык перевести) с определением шаблона класса (файл helper.decl.ixx):

export module hello:helper.decl;

export namespace hello
{

template<typename T>
struct helper
{
   static void
   a();

   static void
   b();
};

} /* namespace hello */

Есть два отдельных module partition unit-а с реализацией методов a и b. В файле helper.impl.a.ixx:

module;

#include <iostream>
#include <typeinfo>

export module hello:helper.impl.a;

import :helper.decl;

export namespace hello
{

template<typename T>
void
helper<T>::a()
{
std::cout << "helper<" << typeid(T).name() << ">::a()" << std::endl;
}

} /* namespace hello */

И в файле helper.impl.b.ixx:

module;

#include <iostream>
#include <typeinfo>

export module hello:helper.impl.b;

import :helper.decl;

export namespace hello
{

template<typename T>
void
helper<T>::b()
{
std::cout << "helper<" << typeid(T).name() << ">::a()" << std::endl;
}

} /* namespace hello */

Все это собирается затем в primary module interface unit:

export module hello;

export import :helper.decl;
export import :helper.impl.a;
export import :helper.impl.b;

export namespace hello
{

void greet();

} // export namespace hello

Описывается в CMake так:

И в случае с clang-ом все OK. Однако.

Для GCC опять таки требуется, чтобы в тестовой программе были сделаны необходимые include. Т.е. вот так OK:

#include <iostream>
#include <typelist>

import hello;

int main()
{
   hello::greet();

   hello::helper<int>::a();
   hello::helper<long>::b();
}

А без include -- ошибка компиляции.

Тогда как для MSVC++ делать include в тестовой программе не нужно, оно компилируется, но зато возникает ошибка линковки:

cmake --build .

[1/1] Linking CXX executable bin\app.exe

FAILED: [code=4294967295] bin/app.exe
C:\WINDOWS\system32\cmd.exe /C "cd . && "C:\Program Files\Microsoft Visual Studio\18\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E vs_link_exe --msvc-ver=1951 --intdir=app\CMakeFiles\app.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100261~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100261~1.0\x64\mt.exe --manifests  -- C:\PROGRA~1\MICROS~2\18\COMMUN~1\VC\Tools\MSVC\1451~1.362\bin\Hostx64\x64\link.exe /nologo app\CMakeFiles\app.dir\main.cpp.obj  /out:bin\app.exe /implib:lib\app.lib /pdb:bin\app.pdb /version:0.0 /machine:x64 /INCREMENTAL:NO /subsystem:console  lib\hello.lib  kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cd ."

LINK: command "C:\PROGRA~1\MICROS~2\18\COMMUN~1\VC\Tools\MSVC\1451~1.362\bin\Hostx64\x64\link.exe /nologo app\CMakeFiles\app.dir\main.cpp.obj /out:bin\app.exe /implib:lib\app.lib /pdb:bin\app.pdb /version:0.0 /machine:x64 /INCREMENTAL:NO /subsystem:console lib\hello.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST:EMBED,ID=1" failed (exit code 1120) with the following output:

main.cpp.obj : error LNK2019: ссылка на неразрешенный внешний символ "public: static void __cdecl hello::helper<int>::a(void)" (?a@?$helper@H@hello@@SAXXZ::) в функции main.

main.cpp.obj : error LNK2019: ссылка на неразрешенный внешний символ "public: static void __cdecl hello::helper<long>::b(void)" (?b@?$helper@J@hello@@SAXXZ::) в функции main.

bin\app.exe : fatal error LNK1120: неразрешенных внешних элементов: 2

ninja: build stopped: subcommand failed.

И здесь я еще в большем недоумении: может это и не вина MSVC++, а проблема в CMake?

Однако впечатление, что под видом модулей комитет очень и очень сильно поднасрал C++ разработчикам, только усилилось.

PS. В очередной раз офигел от документации к CMake. Вроде как там целый раздел посвящен поддержке модулей из C++20. Но в этом разделе я не увидел ни одного примера того, как же модули нужно декларировать в CMakeLists.txt. Пришлось гуглить и потом таскать к себе куски из разных мест.

PPS. Что еще сильно не понравилось, так это то, что с какого-то бодуна стали внедрять новые расширения для module units. Вроде как в мире MS используют .ixx, тогда как в мире clang -- .cppm. Вот нафига и, главное, зачем? Расширения для файлов в C++ном проекте должны быть такими, чтобы можно было в grep одну простую маску задать и все. Поэтому .hpp/.cpp или .hxx/.cxx -- это хорошо, а вот всякие извраты с .H/.C, .hh/.cc и прочим -- фтопку. И если разработчикам навяжут какое-то новое расширение для module units, то удобство C++а лично для меня снизится еще сильнее.

[life.cinema] Очередной кинообзор (2026/05)

2026-06-01T07:28:07.061+03:00

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

Фильмы

Полный Такос (Operation Taco Gary's, 2026). Совершенно укуренный и классный фильм. Мне зашел, но из-за его специфичности рекомендовать не могу -- наверняка понравится не всем. Однако, хороший пример того как за дешево можно снять приличную юмористическую фантастику.

Эдем (Eden, 2024). Хорошая история, хорошая операторская работа, отличная игра актеров. Но вот рассказана эта история так, что не особо и цепляет. Поэтому самые сильные впечатления производят реальные фотографии и кадры хроники, показанные в самом-самом конце.

Они убьют тебя (They Will Kill You, 2026). Неплохая черная комедия в стиле фэнтези с реками крови и грудами отрубленных конечностей.

Взлом на миллион (Wardriver, 2026). Не ждал от фильма ничего хорошего, но был приятно удивлен. Далеко не шедевр, но вполне себе добротный криминальный фильм с неплохими сюжетными ходами.

Нормал (Normal, 2025). Не понял что это было: для комедии вроде бы слишком нудный, для боевика слишком комедийный. Посмотреть можно, но лучше ничего особенного не ждать.

Сезон охоты ("Blood of Man" или "Hunting Season", или "Mermaid", 2025). Добротно, но слишком уж неторопливо и маловато экшОна. По сути, весь фильм держится на харизме Мэла Гибсона.

Мумия ("The Mummy" или "Lee Cronin's The Mummy", 2026). Для своего жанра, в принципе, нормально. Но манера съемки у фильма такая, что воспринимается это все как театральная постановка и поэтому погружения в атмосферу ужаса не происходит.

Охота ("Hunt" или "Heon-teu" или "헌트", 2022). Есть русский бунт, бессмысленный и беспощадный. А есть корейские боевики, не менее бессмысленные и беспощадные 🙂 А если для вас все корейцы на одно лицо и их имена вы не запоминаете вообще, то следить за логикой происходящего на экране будет совсем сложно.

Мститель (Protector, 2025). Что будет, если смешать "Рембо", "Заложницу" и "Джона Уика" в очень-очень бюджетном кино, да еще и с типа крутой теткой в главной роли? А вот унылое говно под названием "Мститель" и получится.

Пастбища богов (2025). Местами красивые пейзажи. Пожалуй, это единственное, что есть хорошего в данном "кино".

Сериалы

Пацаны (The Boys, пятый сезон, 2026). Самый слабый из все сезонов. Но если предыдущие понравились, то надо смотреть хотя бы для того, чтобы увидеть чем все закончилось.

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

Гнев (Man on Fire, первый сезон, 2026). Первые серии бодренькие, затем какие-то тягомотные сопли, а в финале какой-то сплошной маразм. Так что можно смело пройти мимо.

[prog.c++.bugs] Похоже наткнулся на баг в GCC 12/13 под Linux-ом. Или нет.

2026-05-26T07:23:26.887+03:00

Дело было так: есть некий объемный и сложный шаблон класса-контейнера. Для тестирования было создано приложение с юнит-тестами на базе Google.Test. В состав этого приложения входит порядка 30 (тридцати) .cpp-файлов. В некоторых из них происходит следующее:

namespace
{

template<typename T>
struct test_traits : public my_container::default_traits<T> {
  static constexpr std::size_t key_size = 3;
};

} /* namespace anonymous */

TEST(my_container, some_test)
{
  my_container::my_map<int, test_traits> map;
  ... // какие-то действия с map.
}

Т.е. суть в том, что в десятке .cpp-файлов есть анонимные пространства имен, в каждом из которых определяется шаблон класса с именем test_traits. Затем этот шаблон используется для инстанцирования класса-контейнера.

Все это работало до тех пор, пока не был добавлен еще один .cpp-файл, в котором было практически тоже самое:

namespace
{

template<typename T>
struct test_traits : public my_container::default_traits<T> {
  static constexpr std::size_t key_size = 3;
  static constexpr my_container::mode use_mode =
      my_container::mode::versioned;
};

} /* namespace anonymous */

TEST(my_container, some_test_versioned)
{
  my_container::my_map<int, test_traits> map;
  ... // какие-то действия с map.
}

И вот тут-то в some_test_versioned с map стали происходит странные вещи: возникали segmentation faults там, где их быть не должно было. Попытки отладить код приводили к тому, что отладчик показывал, что отрабатывают не те ветки if-ов. А отладочные печати содержали совсем не те значения, которые должны были бы быть.

Было полное ощущение, что GCC сошел с ума.

Проект, в рамках которого все это делается, собирается VC++ под Windows и GCC под Linux-ом. Под Linux-ами используются GCC 12 и 13. Конкретно я работаю с GCC 13, но проверил и под GCC 12. Сам проект уже не очень маленький, плюс подтягивает кучу зависимостей разного калибра (включая Folly и Abseil). Все это к тому, что мероприятие по перекомпиляции проекта под какой-то свежий GCC или clang -- это попытка с негарантированным результатом. Может повезти, а может и нет.

Под Windows проверил, там ничего подобного нет, все работает как и положено. А вот под Linux-овым GCC -- проблемы.

В итоге подумал о том, что GCC воспринимает все мои test_traits как нарушение ODR и я наступаю на грабли UB. Поэтому переименовал test_traits так, чтобы во всех .cpp-файлах имена оказались уникальными, даже не смотря на то, что живут они в анонимных пространствах имен.

После этого все описанные выше магические проблемы разом исчезли.

Есть у меня сильное подозрение, что это таки был баг в GCC. Поскольку, если мне не изменяет склероз, все, что определяется внутри анонимного пространство имен, должно быть абсолютно уникальным. В том числе это касается и шаблонов.

Но на 100% не уверен. Может быть здесь дело еще и в том, что у my_container::map есть шаблонный параметр шаблона, т.е.:

namespace my_container
{

template<typename T, template<typename> class Traits>
class map { ... };

} /* namespace my_container */

Поэтому его параметризация в тесте идет не конкретными типами, а шаблоном:

TEST(my_container, some_test_versioned)
{
  my_container::my_map<
    int, // Это конкретный тип.
    test_traits // А это шаблон, который развернется в конкретный
                // тип уже внутри map.
  > map;
  ... // какие-то действия с map.
}

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

[prog.c++] Обнаружился баг в timertt возрастом более 10 лет

2026-05-21T08:48:40.421+03:00

Пользователи обнаружили в SObjectizer проблему, которая была вызвана неправильной работой механизма timer_heap в библиотеке timertt.

Эта библиотека написана мной осенью 2014-го года для того, чтобы можно было окончательно отвязать SObjectizer от ACE. И как раз тогда, чуть ли не в самой первой версии, допущена ошибка в операции удаления таймерной заявки в механизме timer_heap. Этот timer_heap реализован в виде binary heap на базе вектора. И как раз удаление из вектора и содержало проблему.

То, что я допустил достаточно дурацкую ошибку совсем не удивительно. Я вообще умудряюсь делать на удивление много ошибок при реализации простых структур данных (скажем, если приходится вручную программировать интрузивный двусвязный список, то я там обязательно в паре мест накосячу). Дополнительным отягчающим фактором стало то, что специфическое для timer_heap тестирование было проведено "по верхам". Думаю, что если бы в 2014-ом не поленился составить тест на базе примитивного fuzzing-а, то эта проблема вскрылась бы уже тогда. Но невнимательность + разгильдяйство сделали свое темное дело.

Более удивительно то, что этот баг проявился в полный рост только сейчас, в 2026-ом. Вот это внушаить 🤔

Какие выводы можно сделать?

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

PS. Что меня еще очень сильно удивило, так это то, что люди смогли найти проблемное место в не самом тривиальном (даже для меня) коде. И, к тому же, предложили патч на базе которого я в итоге и сделал исправление. Значит пишу не такой уж и страшный код, если в нем можно разобраться.

PPS. Видимо, нужно найти время и вытащить timertt из старого svn-репозитория на SourceForge чтобы он продолжил жить на GitHub-е. Плюс выбросить оттуда MxxRu и перевести все на CMake (собственно, необходимость бодаться с CMake и является основным стоп-фактором). Нужно как-то себя заставить сделать это. Жаль только, что история коммитов при переносе в git потеряется 🙁

PPPS. Обновление для SObjectizer-а уже опубликовано в виде версии 5.8.5.1.