[prog.c++.sobjectizer] Релиз версии 5.8.5

Намедни состоялся релиз очередной версии 5.8.5.

Нововведений немного. Здесь перечислять не буду, более-менее подробное описание изменений можно найти здесь.

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

По итогу, в 2025-ом удалось сделать два обновления для SO-5 -- одно в январе, одно в ноябре. Что уже неплохо. А если до конца года получится сделать еще одно, хотя бы даже самое маленькое, то будет вообще фантастика.

Очень вероятно, что версия 5.8.5 стала последней, в которой для SObjectizer-а еще используется моя собственная build-система для C++ под названием MxxRu. К сожалению, современным реалиям она уже не удовлетворяет -- нет поддержки параллельной сборки. В теории, можно было бы тряхнуть стариной и попробовать добавить такую возможность в MxxRu.

Но есть другая беда в виде модулей в C++20, которые комитет почему-то счел возможным добавить в стандарт. И вот тыкать эту известную субстанцию не хочется даже трехметровой палкой. Поэтому MxxRu таки уходит в историю. Что печально, т.к. к CMake я все никак не могу привыкнуть и для моего стиля работы в ряде моментов CMake ну вот категорически неудобен 🥺

Если затронуть вопрос дальнейших планов, то в черновом варианте они таковы:

1. изъять следы MxxRu из SObjectizer-а;
2. перевести сопутствующий проект so5extra с MxxRu на CMake. Это, увы, большой кусок неприятной работы;
3. попробовать продвинутся в SObjectizer-е по вот этим двум темам: A custom event_queue inside the agent и The first thoughts about "poison pill" messages. Есть ощущение, что они взаимоувязаны. И если получится что-то придумать с кастомными очередями заявок агентов, то можно добавить в SObjectizer целый ряд новых возможностей: от приоритетов для событий до возможности "откладывать" на время заявки, которые агенту не интересны в данный момент (что-то вроде selective receive из Erlang-a).

В общем, на ближайшие месяцы есть чем заняться. Главное, чтобы возможности для этого находились.

[prog.c++] А зачем в современных условиях нужен обновляемый раз в три года стандарт C++?

Вернуться к теме трехлетнего периода обновления стандарта C++ заставил свежий отчет Герба Саттера о недавнем заседании комитета по стандартизации C++. В частности одна фраза оттуда:

For trivial relocatability, we found a showstopper bug that the group decided could not be fixed in time for C++26, so the strong consensus was to remove this feature from C++26.

Т.е. в одной из фич C++26 обнаружили проблему, исправить эту проблему до принятия C++26 не успевают, поэтому фича из стандарта была выброшена вообще. И, в лучшем случае, она станет частью C++ только в 2029-ом, в рамках C++29.

Что приводит к вопросу о том, а хорошо ли, что C++ обновляется всего раз в три года?

Почему бы не принимать обновленные редакции два раза в год?

Скажем, C++26.1 в марте 2026, а C++26.2 в сентябре 2026. Потом C++27.1 в марте 2027, а C++27.2 в сентябре 2027. И т.д.

Когда конкретное предложение (например, по trivial relocatability) будет готово, тогда оно и попадет в ближайшую редакцию. Не успеет к C++26.1 -- попадет в C++26.2, не успеет к C++26.2 -- значит попадет в C++27.1.

Я это к тому, что этикетка, скажем, C++23, в современных обстоятельствах ничего не значит. Есть на бумаге стандарт C++23, а на практике от этого может не быть никакого толку. Даже если вы сидите на самых свежих компиляторах, все равно в них может не быть полной поддержки C++23. Поэтому отталкиваться приходится не от стандарта, а от версии компилятора. А раз так, то какая разница, не поддерживает компилятор обновляющийся раз в три года стандарт, или же он не поддерживает выходящую два раза в год спецификацию? Как по мне, то никакой.

Так уж получается, что в конце 2025-го года совершенно все равно, является ли std::start_lifetime_as частью C++23 или же частью C++20, или же частью условного C++27.2. Нет start_lifetime_as в нужных мне компиляторах и непонятно когда появится, так что без разницы, приняли ли start_lifetime_as в C++20 или C++23.

Стандарт C++ давным-давно превратился в нечто вроде "заявления о намерениях", которые когда-то как-то может быть будут реализованы. И какой смысл выпускать это "заявление о намерениях" раз в три года? Точно так же можно делать это и два раза в год. В начале 2026-го что-то добавили в C++, затем в конце 2026, затем в начале 2027-го. Все равно затем ждать пару-тройку лет.

Можно предположить, что сама по себе процедура стандартизации C++ не рассчитана на выпуск двух стандартов в год. Типа там много накладных расходов на бюрократию и вот это вот всё.

Однако, можно задать следующий напрашивающийся вопрос: а зачем в современных условиях вообще нужен стандарт C++ именно как ISO-стандарт?

Почему роль этого самого "заявления о намерениях" не может играть некая спецификация, публикуемая от имени некоторой некоммерческой организации? Зачем сейчас развивать C++ под эгидой ISO?

Можно понять значимость стандартизации в начале 1990-х, когда было с полдюжины живых C++ных компиляторов от совершенно разных поставщиков. Некоторые из которых (Borland и Microsoft, как минимум) еще и норовили свои расширения в язык добавлять. В таких условиях роль толстого фолианта с печатью ISO стандарта была понятна.

Но сейчас-то? На фоне того, как постепенно удушающие С++ в смертельных объятиях Java, C#, Go и Rust, вообще не парятся какой-либо стандартизацией. Просто развиваются и просто делают C++ все менее и менее нужным.

В общем, иногда мне кажется, что главным врагом C++ становится сам комитет по стандартизации и его приверженность странным (мягко говорям) правилам работы.

[notebooks] Повсеместный переход на векторные шрифты делают недорогие ноутбуки непригодными для работы

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

За прошедшие годы на собственном опыте наблюдал рост разрешения ноутбучных дисплеев от 640x480 к 800x600, затем к 1024x768, затем 1400x1050... и так до 3840x2160. И вот что характерно: каждый раз переходя от меньшего разрешения к большему происходил рост качества отображения информации на экране. Что графической, что текстовой. Особенно текстовой.

Однако, лет шесть назад попал ко мне в руки замечательный 12.5" ноутбук Dell Latitude в комплектации с TN-матрицей с HD-разрешением (1366x768). И вот тут-то внезапно © выяснилось, что при не самом плохом разрешении для 12.5" экрана качество текста на этом самом экране отвратительное. К концу рабочего дня у меня начинали сильно болеть глаза, а времени за компьютером тогда приходилось проводить очень много. Поэтому через полгода был вынужден перейти на 14" ноутбук с FullHD разрешением (1920x1080).

А год назад попытался пересесть на другой 14" ноутбук тоже с FullHD разрешением, но с соотношением сторон 16:10 (итоговое разрешение 1920x1200). Не смог на нем проработать и месяца 😡 Точно так же болели глаза после 5-6 часов работы за ноутбуком.

Причину для себя нашел в том, что современные ОС (что Windows, что Linux) используют только векторные шрифты. А для того, чтобы эти самые векторные шрифты более-менее нормально выглядели на экранах с невысоким DPI/PPI, применяется сглаживание (в Windows оно известно как ClearType, в KDE оно обозначается как Anti-aliasing).

На 14" FullHD экране это самое сглаживание работает не самым лучшим образом. И если у экрана хорошая контрастность, то это еще не так бросается в глаза. А вот контрастность посредственная, то "замыленность" текста становится заметна. Что и ведет к более быстрой утомляемости.

В качестве эксперимента попробовал подружить Kubuntu на уже упомянутом Dell Latitude с растровыми шрифтами. И заодно отключил Anti-aliasing. Получилось как-то так.

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

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

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

Вот как это выглядит при 4-х кратном увеличении.

Ах, если бы все приложения можно было заставить использовать растровые шрифты... Но тот же Chrome, как я понял, принципиально этого не поддерживает. Как и десктопный клиент для Telegram.

Собственно к чему я это все?

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

Среди того, что у нас в РБ продается за вменяемые деньги (т.е. где-то до ~1500USD) внимание привлек ASUS Vivobook 18 с 18.4" экраном, но разрешением всего лишь FullHD -- 1920x1200. К сожалению, живьем увидеть его не представляется возможным. Но FullHD на 18.4" -- это всего лишь 123 DPI. Что совсем печально. Это даже меньше, чем у HD на 12.5" 🙁

От этого немного грустно.

В продаже имеется некоторое количество ноутбуков от нормальных производителей (Asus, Lenovo, MSI) с приличным железом (современный CPU, 24Gb или 32Gb RAM, SSD от 512Gb), но с FullHD экранами (что 15.6", что 16", что 17", что 18.4"). И этим добром можно было бы спокойно пользоваться, если бы современные ОС и современные приложения (такие как Chrome или Telegram) признавали бы растровые шрифты. Но это, увы, не так.

Поэтому приходится смотреть в сторону ноутбуков с хотя бы 2.5K экранами. Хотя у меня есть подозрение, переходящее в уверенность, что 2.5K на 16" -- это сильно получше, чем FullHD на 14", но все равно эффект "мыла" на тексте для меня заметен. Что заставляет смотреть в сторону 3K экранов. Лучше всего было бы, конечно, 4K. Но ноутбуки с 4K экранами нынче стоят неприлично дорого.

PS. Сейчас у меня два основных рабочих ноутбука: под Linux-ом используется 14" с 2.8K экраном, под Windows -- 14.5" c 3K экраном. На обоих качество текста просто мое почтение. На 15.6" с 4K, конечно же, еще лучше. Но тут уж соревнование отличного с прекрасным 😀 Разницу нужно с микроскопом выискивать.

PPS. Мне кажется, что если ноутбук используется для листания картинок в ленте какой-нибудь сети, просмотре видео из Интернета или игр, то и FullHD на 16" будет вполне достаточно. Но вот у меня все время уходит на работу с текстом -- то постоянно читаешь, то постоянно пишешь, то чередуешь одно с другим. И вот в таких условиях лучшее качество текста на экране из-за больших показателей DPI/PPI становится критически важным.

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

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

Фильмы

Трон: Арес (Tron: Ares, 2025). Отличное детское кино. Очень и очень красиво снятое. Достойное продолжение "Трон: Наследие". Как по мне, так хороший фильм для семейного просмотра. Единственное, чего лично мне не хватило, так это настолько же эпичного саундтрека, как в "Трон: Наследие". Но тот саундтрек -- это вообще уникальное явление, которое происходит раз в несколько десятков лет.

Пойман с поличным (Caught Stealing, 2025). Весьма неплохо, понравилось. Хотя элементы комедии при таком количестве трупов выглядят странно.

Код 3 (Code 3, 2025). Очень специфическое кино. Полагаю, сильно завязанную на особенности американского здравоохранения. Можно посмотреть хотя бы потому, что это очень специфическое кино.

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

Девушка из каюты №10 (The Woman in Cabin 10, 2025). Отличная картинка и к игре актеров нет претензий. Но по сюжету откровенная шляпа. В итоге крайне посредственное кино. Но хотя бы не полный отстой, скоротать вечер вполне можно.

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

Грязная игра (Play Dirty, 2025). Как по мне, так откровенная халтура. Хотя юмор в фильме немного спасает ситуацию. Но именно что немного.

Крутой поворот (Sharp Corner, 2024). Скучно, нудно, затянуто и ни о чем.

Сериалы

Бар "Один звонок" (первый сезон, 2023). Мне понравилось.

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

Рай (Paradise, первый сезон, 2025). Его бы сократить по хронометражу раза в два. Ну и это тот случай, когда на вопрос "а где логика в происходящем?" временами невозможно дать ответ.

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

[prog.c++.bug] Забавный баг подсадил давеча в код

Любопытный случай, достойный того, чтобы быть сохраненным на память.

Был код по типу вот такого:

do {
  ... // Что-то делаем.
} while(!cnt.empty());

Т.е. выполнение каких-то действий до тех пор, пока контейнер не пуст.

После внесения в код новой функциональности данный фрагмент принял вид:

while(a < params.max_value && !cnt.empty()) {
  ... // Что-то делаем.
} while(!cnt.empty());

Т.е. do я убрал и поставил while, но тот while, который остался от do, не удалил 🙁

И, что самое забавное, этот код у меня работал без проблем 🧐
Я даже не знал, что проблема существует, пока коллеги не подсказали.

Очень редко компилируюсь в режиме Debug. В основном в Release, иногда в RelWithDbgInfo. Но не в Debug.

А как раз в Debug ошибка и проявилась. Оставшийся while начал работать как бесконечный цикл.

Полагаю, при компиляции со включенной оптимизацией компилятор трансформировал код так, что при выходе из первого while во второй мы уже не попадали в принципе. А в Debug-режиме оптимизатор ничего не удалял и исполнение после выхода из первого цикла попадало во второй. И баг проявлялся.

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

[prog.c++] Прекрасное от автора функции на 700 строк...

Некоторое время назад в блоге был пост Наткнулся на образчик кода из категории "Да не дай боже такое сопровождать!". Я там прошелся по качеству кода от одного из RSDN-овских форумчан. Код, как по мне, из категории "лучше бы такого никогда не видеть, тем более не сопровождать".

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

Итак, суть в том, что у человека образовалась цепочка из if-else в количестве 200 (двухсот(!!!)) штук. Из-за чего VC++ отказался компилировать данную развесистую конструкцию с ошибкой "MSVC C1061: compiler limit: blocks nested too deeply". И автор топика спрашивает у читателей что можно сделать в такой ситуации.

В одном из своих ответов в начатом обсуждении автор темы привел пример того, с чем он имеет дело:

else if ( opt.setParam("VAR:VAL")       || opt.isOption("set-var") || opt.isOption("set-condition-var") || opt.isOption('C')       || opt.setDescription("Set variable valie for conditions and substitutions")) {    if (argsParser.hasHelpOption) return 0;    if (!opt.hasArg())    {        LOG_ERR<<"Setting condition variable requires argument (--set-condition-var)\n";        return -1;    }    auto optArg = opt.optArg;    if (!appConfig.addConditionVar(optArg))    {        LOG_ERR<<"Setting condition variable failed, invalid argument: '" << optArg << "' (--set-condition-var)\n";        return -1;    }    return 0; }

При этом автор заявляет буквально следующее:

Обработка ключей командной строки.

На какой-нибудь map с хэндлерами не переделать, потому что у меня в режиме --help пробегается по этим условиям и собирает выдаваемую потом информацию. Тут в if сразу и длинный ключ set-var задаётся, и короткий C, и подсказка по формату значения VAR:VAL и описание опции Set variable valie for conditions and substitutions — в одном месте всё задаётся

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

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

Я даже не буду затрагивать тему того, что в продвинутых инструментах для работы с аргументами командной строки многие проблемы уже решены "by design". Например, можно посмотреть на Lyra или args, или даже boost::program_options. Мало ли какие условия заставили человека использовать что-то специфическое (хотя, подозреваю, что им же и написанное). Поэтому сконцентрируемся только на длинной цепочке if-else.

В общем, поскольку в нашем распоряжении только небольшой кусочек демонстрационного кода, то будем отталкиваться именно от него. Из-за чего предлагаемые ниже решения, скорее всего, не подойдут на 100% автору RSDN-новского топика, т.к. наверняка есть какие-то неозвученные на RSDN-е моменты. Но и нет цели показать 100% решение, смысл в том, чтобы показать тот вариант, который лично мне сразу же пришел в голову. И от которого можно оттолкнуться, чтобы избежать длинной портянки из if-else.

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

А раз так, то пусть каждый из блоков представляется в виде std::function. И оба эти блока пусть объединяются в рамках одной структуры:

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

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

Фильмы

Диспетчер (Relay, 2024). Не шедевр, но весьма неплохо. А на фоне остального шлака так даже и хорошо.

Священная дорога (Hallow Road, 2025). Мне понравилось как фильм сделан. Разочаровал разве что открытый финал, который оставляет зрителя без конкретного ответа о том, а что же это было. Но фильм специфический, моей жене, например, совсем не понравился. Так что рекомендовать к просмотру не возьмусь.

84 м² (84jegopmiteo, 2025). Странный фильм. Если нет опыта просмотра корейского кино, то может сильно удивить и разочаровать. Ибо он даже для корейского кино странный. Но мне было интересно.

Никто 2 (Nobody 2, 2025). Я воспринял этот фильм как своеобразную черную комедию с кучей трупов. В этом жанре вполне себе норм. Ни разу не шедевр, но норм. С первым же фильмом, как по мне, сравнивать вообще нельзя, как будто два совершенно разных кино.

Сверху вниз (Highest 2 Lowest, 2025). Скучно и затянуто, плюс на мой взгляд актерская игра в среднем никакая.

Хани, не надо! (Honey Don't!, 2025) Не понял ни что это, ни зачем это. Не увидел ни цели, ни смысла, ни сюжета. Потерянного времени жалко.

Сериалы

Больница Питт (The Pitt, 2025). Мне понравилось, хорошее кино.

13 клиническая. Начало (2024). Если понравился сериал "13 клиническая", то смело можно смотреть и этот. Мне понравились оба.

Черный кролик (Black Rabbit, 2025). Купился на высокую оценку и хорошие рецензии. В итоге очень жаль потраченного на просмотр времени. Где-то на середине уже был не рад, что ввязался, но не бросать же... Претензии не к качеству картинки и не к игре актеров, а с сюжету и происходящему в сериале. Тот самый случай, когда не находишь ни одного положительного персонажа, за развитием которого хотелось бы следить. Плюс в некоторых местах возникает ощущение что нам втирают какую-то дичь.

Чужой: Земля (Alien: Earth, первый сезон 2025). Редкая хрень. Хотя даже несмотря на творившийся маразм было три серии, которые смотрелись интересно и в них чувствовалась атмосфера "Чужих". Но всего три серии из восьми... В общем, не рекомендую и следующий сезон, если даже его решаться сделать, смотреть не собираюсь.

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

Орудия (Weapons, 2025). Не могу оценить. Может быть слишком давно не смотрел подобного кино. Может быть стал слишком старый для этого жанра. Но не оценил. Как по мне, текущая оценка в 7.1 на Кинопоиске слишком завышена.

Миссия невыполнима: Финальная расплата (Mission: Impossible - The Final Reckoning, 2025). Самое точное определение этому дала жена во время просмотра: "Это уже не фантастика и даже не фэнтези -- это уже маразм".