Размышлизмы 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.c++] Эх, давно я не брал в руки SObjectizer...

2026-04-03T14:04:00.000+03:00

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

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

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

Передачу memory_pool-а в дочернюю нить сделал через переменные, защищенные mutex-ом. А чтобы эффективно ждать появление значений в этих переменных -- std::condition_variable. Чтобы получить уведомление от дочерней нити о том, что memory_pool перестал использоваться, задействуется std::promise и std::future. Как-то многовато для того, чтобы прокинуть одну команду из родительской нити в дочернюю, а затем один сигнал обратно 🙁

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

И вот после того, как все это было сделано, стала терзать мысль о том, что на SObjectizer-е с mchain-ами должно же было бы получиться проще. Терзала она меня, терзала, и в конце-концов заставила потратить немного времени, чтобы сделать вариант на SO-5.

Ну и что хочу сказать? 😉

На SO-5 и компактнее, и проще, и понятнее. На мой сугубо субъективный взгляд.

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

Получается тривиальное взаимодействие: в родительской нити сперва send, затем receive, а в дочерней нити сперва receive из которого уже делается send в обратном направлении.

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

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

автоматическое завершение дочерней нити в SObjectizer-варианте как раз уже обеспечивается за счет использования auto_joiner-ов и auto_closer-ов;
контроль тайм-аутов ожидания в случае с so_5::receive добавляется элементарно. В случае с примитивами из C++ной библиотеки, в принципе, тоже не сложно, но телодвижений, имхо, все-таки чуть-чуть побольше потребуется.

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

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

2026-04-02T07:47:00.001+03:00

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

Фильмы

Аватар: Огонь и пепел (Avatar: Fire and Ash, 2025). Лично мне понравился гораздо больше, чем вторая часть. Ничем не удивил, но это образец отлично сделанного аттракциона, после которого не жалко потраченного времени.

Ограбление в Лос-Анджелесе (Crime 101, 2026). В принципе, норм. Но мне не хватило экшена и показалось, что фильм излишне затянут.

Военная машина (War Machine, 2026). Красочно, динамично, прямолинейно, тупо и пафосно. При желании можно посмотреть, а можно и проигнорировать данное "кино".

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

На помощь! (Send Help, 2026). Не понял что это было: для серьезного триллера слишком много дурацкого юмора и откровенного треша, для чернушной треш-комедии слишком мало дурацкого юмора и откровенного треша. Как сюда занесло Рейчел МакАдамс просто загадка.

Крик 7 (Scream 7, 2026). Динамично, кроваво. Но тупость большинства персонажей множит все хорошее на ноль.

Адское пламя (Hellfire, 2026). Мог бы быть душевный боевичок в стиле 1980-х с сильно постаревшими, но крутыми в прошлом актерами, если бы не нарисованная на компьютере стрельба. Такая откровенная дешевизна убивает все хорошее, что в фильме могло бы быть. Можно смело пройти мимо и не тратить свое время.

Тропа гнева (2025). Откровенная халтура, лучше не смотреть.

Иерархия (Hierarchy, 2025). Дешевая поделка. Не стоит тратить на это время.

Сериалы

Подслушано в Рыбинске (первый сезон, 2024). Отличное кино, посмотрел с удовольствием.

Ограбление (Steal, первый сезон, 2025). Нормально. Есть пара моментов, к которым мне бы хотелось придраться, но в целом можно смотреть.

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

Захваченный рейс (Hijack, второй сезон, 2026). К сожалению, можно лишь повторить то, что писал про первый сезон: "Отлично снято и к игре актеров нет претензий. Пожалуй, это все хорошее, что можно сказать про этот сериал. Остальное, как по мне, одни недостатки." Если кому-то понравился первый сезон, то можно глянуть и второй. А вот если не понравился или не смотрели, то лучше бы пройти мимо.

Незнакомка (The Stranger, 2020). Смотреть интересно, но когда сезон заканчивается и начинаешь анализировать итоги, то складывается ощущение, что "нам втирали какую-то дичь".

[prog.c++] Говорят, что основная работа над C++26 завершена

2026-03-30T18:45:00.000+03:00

Например, об этом написал Герб Саттер. Типа в C++ теперь есть и рефлексия, и контракты, и даже уменьшено число UB. Уж теперь-то точно заживем.

У меня, однако, отношение к данному событию весьма равнодушное.

Ну вот не отношусь к счастливчикам, которые пилят один проект для одной платформы на одном компиляторе. Посему не могу сидеть на самом свежем GCC (или clang-е, или MSVC) под самой-самой свежей ОС и наслаждаться плюшками самого свежего C++. До меня эти нововведения доходят спустя годы. Так что если смогу задействовать C++26 в продакшене году эдак в 2029-ом, то и хорошо.

Кроме того, в современный C++ завозят, вроде бы, крайне полезные вещи, но в таком виде, что оторопь берет.

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

Ну или взять контракты. В Eiffel-е -- это одна из самых классных фич языка, можно сказать киллер-фича. Тогда как в C++26 я что-то не вижу возможности использования old в постусловиях. Такое ощущение, что в C++ных контрактах мне не получится написать что-то вроде:

void push_back(T v) post(this->size() == old this->size() + 1)
{...}

Если я ошибаюсь, то буду признателен за подсказку о том, как такой фокус в C++ных контрактах осуществить.

В общем, для кого-то C++ в очередной раз стал лучше. Но пока что не для меня, т.к. моя основная рабочая лошадка -- это C++17 и, местами, C++20. Однако тех, кому нововведения в C++26 нравятся и кто сможет начать их применять в ближайшее время, можно поздравить.

[prog.c++] Как будто бы недоделки в системе C++ных аллокаторов

2026-03-09T13:15:00.000+03:00

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

Первая штука -- это отсутствие каких-то простых инструментов для создания нового объекта посредством аллокатора.

Если нам не нужно связываться с аллокаторами, то мы просто вызываем new T (или make_unique<T> или make_shared<T>) и все.

А вот в случае с аллокаторами сперва нужно вызвать у аллокатора allocate чтобы получить блок памяти под объект. А затем нужно вызывать у аллокатора construct, чтобы сконструировать объект в этом блоке. Т.е. два действия вместо одного. При этом, если construct бросает исключение, то нужно вручную освободить блок памяти посредством обращения к deallocate у аллокатора.

Но вот простого метода, который бы сперва сам вызвал allocate и следом construct, в стандартной библиотеке я не нашел. Есть там make_obj_using_allocator, но он вроде как для совсем другого.

Так же нет простого метода, который бы взял ссылку на аллокатор и указатель на удаляемый объект и сам бы сперва вызвал destroy для объекта, а потом deallocate для блока памяти. А хотелось бы иметь готовый, а не делать самостоятельно на коленке.

И да, я знаю, что allocate/construct и destroy/deallocate вызываются через allocator_traits, просто не упоминаю об этом для простоты изложения.

В C++17 в стандартную библиотеку добавили std::pmr::memory_resource. И, вроде как, имеет смысл делать свои арены в виде наследников от memory_resource.

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

И тут вопрос: а как быть, если мы не хотим получать исключение? Например, нам хотелось бы иметь аналог new(std::nothrow). Типа попробовали выделить память, если не получилось, то у нас на руках нулевой указатель и мы можем попробовать обработать эту ситуацию без try..catch блока (ведь try..catch -- это дорого).

Мне кажется, что в memory_resource напрашивается метод allocate формата:

void *
allocate(std::nothrow_t,
  std::size_t bytes,
  std::size_t alignment = alignof(std::max_align_t));

и соответствующий ему метод do_allocate.

Но почему-то этого нет 🙁

У аллокатора есть свойство, которые выражаются вложенным типом propagate_on_container_copy_assignment. Если оно эквивалентно std::true_type, то аллокатор должен копироваться при копировании содержимого контейнера в операторе копирования.

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

some_container original{ ... };
...
some_container copy{ original }; // (1)

В точке (1) должен быть вызов original.get_allocator().select_on_container_copy_construction().

Что мне кажется странным и несколько недодуманным, так это то, что потенциально propagate_on_container_copy_assignment и select_on_container_copy_construction могут быть не согласованы.

Т.е. свойство propagate_on_container_copy_assignment может быть std::false_type (а по умолчанию это так и есть), при этом select_on_container_copy_construction может возвращать тот же самый аллокатор. Что приведет к тому, что в конструкторе копирования у нас будет копироваться аллокатор из контейнера-источника. А вот в операторе копирования мы аллокатор из источника копировать уже не будем.

А может быть и другой вариант: propagate_on_container_copy_assignment -- это std::true_type, тогда как select_on_container_copy_construction будет возвращать новый экземпляр аллокатора (не равный исходному). Тогда в конструкторе копирования мы будем получать новый экземпляр аллокатора, а в операторе копирования -- будем получать копию аллокатора из контейнера-источника.

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

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

[prog.c++] Применимость идиом copy-then-swap и move-then-swap при наличии кастомных аллокаторов

2026-03-02T10:02:00.002+03:00

В продолжение недавно начатой темы. Есть очень удобная идиома copy-then-swap, которая позволяет легко и просто написать для своего типа оператор копирования, обеспечивающий строгую гарантию безопасности исключений.

Для примера рассмотрим некий вымышленный тип, который содержит внутри пару векторов:

class special_container {
  struct description { ... };
  struct payload { ... };

  std::vector<description> m_descriptions;
  std::vector<payload> m_payloads;
...
};

И мы хотим, чтобы у special_container был оператор копирования со строгой гарантией безопасности исключений. Для этого нам потребуются:

обычный конструктор копирования;
не бросающий исключений swap.

что достигается весьма просто:

class special_container {
  ...
public:
  // Swap сделаем через свободную функцию.
  friend void swap(special_container & a, special_container & b) noexcept
  {
    using std::swap;
    swap(a.m_descriptions, b.m_descriptions);
    swap(a.m_payloads, b.m_payloads);
  }

  // Конструктор копирования.
  special_container(const special_container & other)
    : m_descriptions{ other.m_descriptions }
    , m_payloads{ other.m_payloads }
  {}
...
};

Имея в своем распоряжении эти базовые инструменты можно сделать и оператор копирования:

special_container &
special_container::operator=(const special_container & other)
{
  special_container tmp{ other };
  swap(*this, tmp);
  return *this;
}

Фокус здесь в том, что возможные исключения вылетят при формировании объекта tmp. Но при этом ничего не меняется в this. А если при конструировании tmp исключений не случилось, то мы заменяем содержимое this содержимым tmp.

Еще один приятный фокус в том, что такая примитивная реализация прекрасно защищает и от присваивания самому себе. Впрочем, если экземпляры special_container "тяжелые", а вероятности самоприсваивания не нулевая, то можно и по старинке:

special_container &
special_container::operator=(const special_container & other)
{
  if(this != std::addressof(other))
  {
    special_container tmp{ other };
    swap(*this, tmp);
  }
  return *this;
}

Пока что все идет замечательно.

Но давайте представим себе, что нам потребовалось научить special_container работать с разными аллокаторами. Т.е. тип special_container превращается во что-то вроде:

Сможем ли мы и дальше пользоваться идиомой copy-then-swap?

И вот тут у меня есть сомнения. А в попытках разобраться как раз и получился этот пост.

У аллокатора может быть такое свойство как propagate_on_container_swap. Если это свойство выставлено в std::true_type, то при выполнении swap мы можем обменять аллокаторы для контейнеров.

Грубо говоря, допустим, что у нас есть собственный тип аллокатора:

class special_allocator {
  ...
public:
  // Указываем, что обмен аллокаторами поддерживается.
  struct propagate_on_container_swap : public std::true_type {};

  // Явно говорим, что экземпляры аллокаторов отличаются.
  struct is_always_equal : public std::false_type {};
  ...
};

В этом случае мы можем сделать вот так:

special_allocator first_allocator{...};
special_allocator second_allocator{...};
assert(first_allocator != second_allocator);

std::vector<int, special_allocator> first{ first_allocator };
std::vector<int, special_allocator> second{ second_allocator };
...
swap(first, second);

Т.е. пока что все вроде бы понятно и логично.

Но что, если propagate_on_container_swap определен как std::false_type (или не определен, что приравнивается к std::false_type)?

В этом случае обмен аллокаторами при выполнении swap невозможен.

Более того, если у контейнеров аллокаторы не равны, то выполнение swap уже является undefined behaviour. Т.е. вот в этом случае:

class special_allocator {
  ...
public:
  // Указываем, что обмен аллокаторами НЕ поддерживается.
  struct propagate_on_container_swap : public std::false_type {};

  // Явно говорим, что экземпляры аллокаторов отличаются.
  struct is_always_equal : public std::false_type {};
  ...
};
std::vector<int, special_allocator> first{ first_allocator };
std::vector<int, special_allocator> second{ second_allocator };
assert(first_allocator != second_allocator);
...
swap(first, second);

Мы получаем UB.

И знаете, что интересно?

Что у штатных аллокаторов в стандартной библиотеке С++, например, у std::allocator и std::pmr::polymorphic_allocator свойство propagate_on_container_swap выставлено в std::false_type.

И если для std::allocator это компенсируется значением is_always_equal, то вот для std::pmr::polymorphic_allocator еще и is_always_equal является std::false_type.

Получается, что как только я делаю special_container шаблоном, параметризуемым типом аллокатора, то реализация оператора копирования через идиому copy-then-swap становится некорректной.

Давайте взглянем на нее еще раз:

template<typename Alloc>
special_container<Alloc> &
special_container<Alloc>::operator=(const special_container<Alloc> & other)
{
  special_container tmp{ other }; // (1)
  swap(*this, tmp); // (2)
  return *this;
}

Здесь в точке (1) мы получаем новый контейнер, у которого будет собственный аллокатор. И этот аллокатор может отличаться от аллокатора, который есть у this.

Соответственно, операция swap может вести к UB если:

у аллокатора свойство propagate_on_container_swap -- это std::false_type;
у аллокатора свойство is_aways_equal -- это std::false_type;
у tmp и this не равные друг другу экземпляры аллокаторов.

Т.е. вот в этом случае:

class special_allocator {
  ...
public:
  // Указываем, что обмен аллокаторами НЕ поддерживается.
  struct propagate_on_container_swap : public std::false_type {};

  // Явно говорим, что экземпляры аллокаторов отличаются.
  struct is_always_equal : public std::false_type {};
  ...
};

special_allocator first_allocator{...};
special_allocator second_allocator{...};
assert(first_allocator != second_allocator);

special_container<special_allocator> first{ first_allocator };
special_container<special_allocator> second{ second_allocator };
... // Наполнение контейнеров.
first = second; // (3)

в точке (3) у нас будет UB из-за использования swap-а в реализации operator= для special_container.

Как я смог понять, выход в том, чтобы при создании tmp внутри operator= явным образом задать для tmp нужный allocator. Что-то вроде:

И тут, казалось бы, можно было бы поставить точку и выдохнуть. Если бы не одно "но": у аллокатора есть свойство propagate_on_container_copy_assignment. Если оно соответствует std::true_type, то при копировании контейнеров должно происходить копирование аллокатора. Т.е. в этом случае мы не можем создать tmp с использованием старого аллокатора.

И тут начинает казаться, что с учетом свойства propagate_on_container_copy_assignment проще делать оператор копирования без идиомы copy-then-swap:

template<typename Alloc>
special_container<Alloc> &
special_container<Alloc>::operator=(const special_container<Alloc> & other)
{
  if(this != std::addressof(other))
  {
    m_descriptions = other.m_descriptions; // (4)
    m_payloads = other.m_payloads;
  }
  return *this;
}

Ведь в этой тривиальной реализации все должно бы произойти автоматически: если propagate_on_container_copy_assignment предписывает копировать аллокатор, то это произойдет автоматически при копировании m_descriptions и m_payloads. А если копировать аллокаторы не нужно, то это также автоматически будет учтено в тех же самых копированиях.

Однако, при этом мы имеем только базовую гарантию безопасности исключений. И достаточно специфическую. Давайте представим себе, что аллокатор требует своего копирования (т.е. propagate_on_container_copy_assignment -- это std::true_type). И исключение у нас происходит в точке (4).

В этом случае в m_descriptions, скорее всего, уже будет аллокатор из other. Но в каком состоянии содержимое m_descriptions -- мы толком не знаем. Старого содержимого там, наверняка, уже нет. А вот что там из нового -- непонятно.

Тогда как m_payloads мы тронуть еще не успели и он остался в своем исходном виде. Со своим первоначальным аллокатором.

Как по мне, так получить экземпляр special_container в таком неопределенном состоянии -- это то еще удовольствие. Поэтому есть ощущение, что можно было бы сделать так:

template<typename Alloc>
class special_container
{
  struct description {};
  struct payload {};

  using alloc_traits = std::allocator_traits<Alloc>;
  using description_allocator = alloc_traits::template rebind_alloc<description>;
  using payload_allocator = alloc_traits::template rebind_alloc<payload>;

  // Содержимое контейнера. Собрано в одном месте дабы проще
  // было его полностью заменять.
  struct content
  {
    // Аллокатор, который мы будем использовать.
    Alloc m_allocator;

    std::vector<description, description_allocator> m_descriptions;
    std::vector<payload, payload_allocator> m_payloads;

    content(const Alloc & alloc)
      : m_allocator{ alloc }
      , m_descriptions{ alloc }
      , m_payloads{ alloc }
    {}
    content(const Alloc & alloc,
      const std::vector<description, description_allocator> & descriptions,
      const std::vector<payload, payload_allocator> & payloads)
      : m_allocator{ alloc }
      , m_descriptions{ descriptions, alloc }
      , m_payloads{ payloads, alloc }
    {}
    // Для перемещения нам достаточно того, что сгенерирует компилятор.
    content(content && other) noexcept = default;
  };
  content m_content;
...
public:
  // Выполнение требований к allocator aware container.
  using allocator_type = Alloc;
  [[nodiscard]] allocator_type
  get_allocator() const { return m_content.m_allocator; }

  // Специальный вариант конструктора копирования, который получает
  // экземпляр аллокатора.
  special_container(
    // Откуда берем содержимое.
    const special_container & other,
    // Аллокатор, который должны использовать.
    const Alloc & allocator)
    : m_content{ allocator, other.m_descriptions, other.m_payloads }
  {}
  ...
  // Оператор копирования.
  special_container &
  operator=(const special_container & other)
  {
    if(this != std::addressof(other))
    {
      // Определяем какой именно аллокатор должен использоваться в копии.
      const auto & new_copy_alloc =
        alloc_traits::propagate_on_container_copy_assignment::value
        ? other.get_allocator() // Нужно забирать из other.
        : this->get_allocator() // Нужно оставлять свой.
        ;

      // Первая часть copy-then-swap.
      content new_content{ new_copy_alloc, other.m_descriptions, other.m_payloads };
      //
      //  ВАЖНО: ниже по коду исключений уже не ждем.
      //
      // Вторая часть copy-then-swap состоит из уничтожения текущего content...
      m_content.~content();
      // ...и его пересоздания по месту.
      new(m_content) content{ std::move(new_content) };
    }
    return *this;
  }
};

Понятное дело, что в таком случае придется всю работу с m_content в special_container делать через std::launder. Но это уже дело техники.

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

Отдельным моментом стоит использование идиомы move-then-swap в реализации оператора перемещения.

Пока мы не связываемся с аллокаторами, у нас нет проблем с оператором перемещения, который красиво и просто делается через move-then-swap:

special_container::special_container(special_container && other) noexcept
  : m_descriptions{ std::exchange(
      other.m_descriptions, std::vector<description>{}) }
  , m_payloads{ std::exchange(
      other.m_payloads, std::vector<payload>{}) }
{}

special_container &
special_container::operator=(special_container && other) noexcept
{
  special_container tmp{ std::move(other) };
  swap(*this, tmp);
  return *this;
}

Но вот как только в дело вступают аллокаторы, так все становится гораздо интереснее.

Есть ощущение, что в таком случае будет что-то вроде:

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

Буду признателен, если в моих рассуждениях обнаружатся ошибки или недоработки, на которые мне любезно укажут.

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

2026-03-01T08:48:00.000+03:00

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

Фильмы

Человек с Земли (The Man from Earth, 2007). Фильм очень не новый, но посмотрел его только сейчас. Как по мне, так отличное кино, базирующееся на хорошем сюжете и тщательно выстроенных диалогах.

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

Убийца в петле времени (Kill Me Again, 2023). На удивление хорошо. Тот редкий случай, когда не ждешь вообще ничего хорошего, а получаешь нормально сделанное кино с вменяемой развязкой. Ну и, прямо скажем, неожиданная вариация на тему "дня сурка".

Бастион 36 (Bastion 36, 2025). Неплохая криминальная драма. Но мне не хватало динамики, какие-то эпизоды просто проматывал, т.к. ну очень уж скучно было.

Казнить нельзя помиловать (Mercy, 2026). Первые 2/3 было прям хорошо. Затем началось что-то невнятное в виде погони и вокруг нее, что очень сильно испортило впечатление. В конце есть хороший твист, который, к сожалению, испорченное впечатление исправить уже не смог.

Сериалы

Мошенники (второй сезон, 2026). Отличное продолжение отличного сериала.

Ночной администратор (The Night Manager, второй сезон, 2025). Если понравился первый сезон, то можно посмотреть и второй. Местами второй похуже (мне выбор некоторых актеров показался странным), местами получше. Буду ждать продолжения.

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

Вторая семья (первый сезон, 2023). Купился на очень высокий рейтинг на Кинопоиске. Как по мне, средней паршивости. Основной сюжет вроде норм, но некоторые детали оставляют вопросы "ну как так-то?"

Его и её (His & Hers, первый сезон 2026). Смотрибельно, хотя идиотизм некоторых персонажей меня откровенно раздражал. Финал неожиданный, но, как по мне, выглядит несколько чужеродно и притянуто за уши.

Художник (второй сезон, 2025). Начало еще более-менее смотрибельно, но вот завершение -- это просто какой-то позор.

[prog.c++] Обеспечивает ли vector::operator=(const vector &) строгую гарантию безопасности исключений?

2026-02-27T19:10:00.000+03:00

Если задать какому-нибудь ИИ простой вопрос о гарантиях безопасности исключений оператора присваивания для std::vector, то можно получить однозначный ответ: мол, обеспечивается строгая гарантия. Т.е. если в процессе работы оператора копирования возникнет исключение, то целевой вектор останется в своем исходном виде.

Однако, не все так однозначно™

Пункт первый, далеко не очевидный

std::vector зависит от аллокатора. Хотя, наверное, мало кому доводилось использовать std::vector с аллокатором, отличным от std::allocator. Тем не менее, у вектора есть аллокатор. А у аллокатора есть такое свойство как propagate_on_container_copy_assignment (см., например, здесь). И если это свойство предписывает скопировать в вектор-приемник аллокатор из вектора-источника, то тут возникает тонкий момент: старое содержимое вектора-источника должно быть удалено посредством старого аллокатора.

Если глянуть как этот момент учитывается в реализациях стандартной библиотеки (libstdc++ от GCC или libcxx от LLVM), то можно увидеть, что сперва уничтожается старое содержимое вектора, и лишь затем делается попытка копирования содержимого вектора источника.

Особенно хорошо это видно на примере libstdc++v3:

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

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

Пункт второй, более очевидный

Многое зависит еще и от того, какие гарантии безопасности исключений дает сам тип T, который хранится в vector-е. Если посмотреть на одну из ветвей работы оператора присваивания в libstdc++v3, то можно увидеть, что новое содержимое записывается поверх старого:

А раз так, то мы сильно зависим от того, бросают ли исключения операторы копирования у T. Если бросают, то может случиться следующее:

первые N элементов из вектора-источника будут скопированы;
на (N+1) элементе возникнет исключение, операция копирования будет прервана.

Получится, что первые N элементов у вектора-приемника получат новые значения, а оставшиеся -- сохранят старые. При это непонятно что будет с (N+1): если у T::operator= строгая гарантия безопасности исключений, то сохранится старое. А вот если нет... Тогда этот элемент окажется в непонятном состоянии.

В сухом же остатке имеем то, что если в операторе копирования для вектора возникнет исключение в T::operator=, то вектор может изменить свое состояние (часть будет иметь новое значение, часть старое). А это никакая не строгая гарантия безопасности.

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

template<typename T, typename Alloc>
void strong_guarantee_copy(vector<T, Alloc> & dest, const vector<T, Alloc> & src)
{
vector<T, Alloc> fresh_copy{ src, dest.get_allocator() };
swap(dest, fresh_copy);
}

В этом случае мы сперва получаем копию. Или исключение, если копия не создается по каким-либо причинам. А уже потом перемещаем это новое значение в dest.

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

[prog.c++] Дошел до чистого безумия: new(this) another_object_type

2026-02-20T13:16:00.000+03:00

Тяжкая судьба C++программиста довела использования в коде трюка, про который еще несколько лет назад и вовсе не знал. Речь про замену типа объекта через вызов placement new внутри метода самого заменяемого объекта.

В моем случае получился код вроде вот такого:

template< typename ValueT >
void
special_map< ValueT >::fixed_capacity_node::insert_item( ValueT value )
{
   auto & self = this->self_data();
   if( self.size() < self.capacity() )
   {
      ... // use the existing node.
   }
   else
   {
      ... // prepare internal data for a new node type.

      // Replace the node by an instance of the new type.
      new(this) dynamic_capacity_node{ std::move(new_node_internal_data) };
   }
}

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

Еще несколько лет назад мне и в голову не приходило, что такое возможно. Однако, когда изучал тему std::launder, то наткнулся на подобный трюк. И вот теперь сам дошел до его применения.

PS. Никому не советую повторять подобное в домашних условиях. Как говорится, все показанное было выполнено специально подготовленными профессионалами 😎 Были предприняты различные предохранительные меры дабы удостоверится, что fixed_capacty_node и dynamic_capacity_node идентичны и по размеру, и по выравниваю. И что после смены типа объекта никто не обращался к нему по старому указателю без std::launder.

[business] Практические выводы из того, что успешный результат в бизнесе не гарантирован

2026-02-09T14:22:00.000+03:00

В догонку к предыдущему посту. Осталось ощущение, что сказал "А", но не стал говорить "Б". Посему предлагаю вернуться к теме о том, что успех в бизнесе не гарантирован и рассказать о некоторых практических выводах из этого утверждения.

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

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

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

И так снова и снова.

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

Вот этот вот переход от "и тогда точно..." к "посмотрим что" оказался ключевым чтобы избавиться от дополнительных переживаний и нервного напряжения. Хотя бы в некоторой степени.

Когда бизнес только потребляет средства и пока еще ничего не приносит, то помогает четко обозначенный порог потерь, на которые ты готов пойти. Типа того, что определяется сумма, с которой готов расстаться. Например, вкладываю N денег в течении M месяцев. Если в итоге не выходим на окупаемость с перспективами для прибыльности, то просто закрываемся, списываем потери, осмысливаем полученные уроки и движемся дальше.

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

Только вот, скорее всего, это всего лишь отсрочка неизбежного. И лучше таки резать сразу, не дожидаясь перитонита. Чтобы потерять только N денег, а не N умноженное на X, плюс потраченное впустую дополнительное время, которое вообще никак не вернуть.

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

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

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

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

Нужно как-то научиться спокойно относиться к потере собственных денег.

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

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

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

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

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

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

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

Отсюда еще один, если можно так сказать, совет: не стоит затягивать с попыткой начать свое дело. Если в 35 вы задумались о том, что пора открывать что-то свое, то лучше не откладывать это до 45. Можно попробовать в 36 и к 45 совершить несколько попыток. Либо что-то увенчается успехом, либо вы поймете, что в найме все-таки спокойнее и денежнее и будете тихо встречать неизбежно приближающуюся старость ;)

[business] О чем вам не раскажут бизнес-спикеры с YouTube

2026-02-02T07:44:00.000+03:00

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

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

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

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

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

Можно посмотреть, скажем, на велогонщиков. В гранд-турах, вроде Вуэльты или Тур-де-Франц, участвуют порядка 200 спортсменов, но победы на этапах одерживает дай бог если пара десятков, а на общую победу даже в теории претендуют только единицы. Причем это все гонщики ТОП-ового мирового уровня, на которых приходятся тысячи тех, кто даже никогда до гранд-тура не доберется в принципе.

Значит ли это, что абсолютно все те, кто не побеждает, просто недостаточно подготовлены? Что они просто мало тренируются или не соблюдают спортивный режим? Не следуют рекомендациям тренеров, спортивных врачей и других специалистов?

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

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

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

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

Ага. Как же.

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

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

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

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

2026-02-01T15:35:00.000+03:00

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

Фильмы

Лакомый кусок (The Rip, 2025). Смотрибельно. Но по ходу всего фильма не мог отделаться от ощущения, что диалоги какие-то странные: о чем-то персонажи говорят, но какой-то связности, целостности и последовательности не ощущается. Может быть проблема в переводе.

Достать ножи: Воскрешение покойника (Wake Up Dead Man, 2025). Гораздо лучше, чем вторая часть, вполне можно смотреть. Но для меня здесь слишком много театральщины и пафоса, что сильно портит впечатление.

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

Опасный дуэт (The Wrecking Crew, 2026). Не понравилось. Была всего одна или две приличных экшен-сцен, все остальное какая-то скучная муть. Ну и 50-летние дядьки, которые играют 25-летних малолетних дебилов смотрятся еще большими дебилами, чем их герои.

Джентльмен (Ya No Quedan Junglas, 2025). Откровенная халтура, смело можно не смотреть.

Сериалы

Чудовище внутри меня (The Beast in Me, первый сезон, 2025). Очень даже ничего. Не могу сказать, что прям "Вау!", но сюжет хороший, не затянуто, отличная игра актеров. Даже гомосексуальная повестка, которую сюда впихнули, в принципе, оказалась оправдана.

Злые люди (первый сезон, 2025). Очень посредственно. Все очень лубочное и все персонажи какие-то картонные, безжизненные.

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

[prog.thoughts] Как ИИ может отбирать хлеб у разработчиков библиотек

2026-01-26T07:15:00.002+03:00

Сразу хочу жирный disclaimer: я не утверждаю, что сказанное мной ниже уже является реальностью. Но есть ощущение, что к этому идет. Буду только рад, если в итоге ошибусь.

Еще десять лет назад у разработчиков OpenSource продуктов была такая опция для монетизации своей работы как платные консультации и платное обучение. Грубо говоря, есть открытая библиотека X за которой стоит компания Y. И если вы не можете разобраться с X самостоятельно, то обращаетесь к Y за помощью, а Y направляет к вам людей, которые учат вас, отвечают на ваши вопросы и подсказывают вам какие-то решения, которые вы не видите в силу своего незнания X.

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

Грубо говоря, если 10 лет назад я рассчитывал на то, что вокруг OpenSource можно зарабатывать на трех вещах:

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

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

Чтобы затронуть еще один важный момент нужно ответить на вопрос, а зачем вообще нужны библиотеки?

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

Почему библиотеки возникли?

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

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

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

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

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

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

И чем лучше и удобнее были те самые библиотеки, тем проще было прикладным программистам.

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

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

[prog.flame] Пробелы таки выигрывают у табуляции?

2026-01-20T09:23:00.001+03:00

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

А вот когда узнал, году эдак в 1992-ом, то практически сразу же перешел с пробелов на табуляции, ибо:

исходные файлы с табуляцией занимали гораздо меньше места. Что было более чем критично во времена дискет на 1.2 MiB. Ведь тогда в наших палестинах самыми распространенными были 5.25" дисководы и дискеты на 360 KiB, 720 KiB и 1.2 MiB (хотя не везде диски на 1.2 MiB нормально читались и писались). Гораздо более надежные и практичные 3.5" дискеты на 1.44 MiB в нашей местности получили распространение спустя несколько лет. Архиваторы, вроде pkzip и arj уже были, но вроде бы исходники с пробелами все равно сжимались хуже;
текстовые редакторы для программистов тогда были гораздо более убогими, чем сейчас. Я не припомню редакторов, которые бы по клавише Tab и по сочетанию Shift+Tab двигали бы выделенный блок текста вправо или влево. Поэтому если тебе нужно было изменить выравнивание куска кода, то приходилось делать это вручную, и с табами было это гораздо быстрее и проще;
в те времена достаточно распространенной практикой была распечатка текстов программ. Сейчас это кажется диким, а 35 лет назад машинное время было дефицитом и ты не мог сидеть за компьютером часами на пролет в поиске какого-то заковыристого бага -- тебе этого просто не позволяли, а собственных персональных IBM PC-совместимых компьютеров в те времена практически ни у кого не было. В текстовом редакторе можно было выставить размер табуляции в 2 символа и видеть больше на тогдашних 14" EGA/VGA экранах с текстовым режимом 80x25 символов, а для печати использовать размер в 4 символа и получать более удобный для чтения формат. Тогда как с пробелами такой фокус уже не проходил.

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

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

Во-вторых, мне по работе периодически приходится вставлять куски кода в e-mail-ы или документы Google.Doc. Типа вот есть такой фрагмент, в нем вот здесь и вот здесь есть вот такие и такие проблемы, исправить их можно вот так и вот так, а еще лучше было бы переписать вот так или вот так. Но, к сожалению, со вставкой кусков кода с табуляцией внутри могут возникнуть проблемы. Так, если я пишу письмо прямо в Web-интерфейсе Google Mail, то при отправке письма все табы вырезаются и форматирование кода оказывается полностью сломано -- весь текст просто прижимается к левому краю 😡 Если фрагмент вставляется в Google.Doc, то форматирование более-менее сохраняется, но вносить в такой фрагмент правки -- это то еще приключение.

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

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

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

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

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

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

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

2026-01-02T11:35:00.000+03:00

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

Фильмы

Первый на Олимпе (2025). Мог бы получиться просто отличный фильм, если бы не главный злодей, которого сделали настолько злодейским, что прям караул.

Бугония (Bugonia, 2025). Очень необычное кино. И посмотреть его можно только из-за того, что это очень необычное кино. Но нужно перетерпеть первые 2/3 фильма, т.к. все самое интересное начинается именно в конце.

Грабитель с крыши (Roofman, 2025). Хорошее и доброе кино.

Годзила: минус один (Gojira -1.0). Весьма неплохо. Снято за копейки, но в подавляющем большинстве случаев все деньги реально видны на экране (за редким исключением). Если бы не азиатская актерская школа, когда истерики доведены до максимума, так было бы просто зашибись.

Битва за битвой (One Battle After Another, 2025). Вот вообще не понял что это было. В меня кино совершенно не попало. И еще я не понял, почему считается, что главная звезда в этом фильме ДиКаприо, как по мне, так все держится на Шоне Пенне.

Бегущий человек (The Running Man, 2025). Редкий бред и редкий тупизм. Но бодренько, да.

Сериалы

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

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

В её глазах (Behind Her Eyes, первый сезон, 2021). Смело можно было бы сократить хронометраж раза в два. Тогда бы могло получиться что-то достойное. А так нудная нудятина, да еще и основной твист угадывается еще в предпоследней серии.

Тоннель (первый сезон, 2025). Какой-то сказочный мир в котором какие-то сказочные персонажи творят какую-то сказочную хрень. Смело можно не смотреть.

Последний рубеж (The Last Frontier, первый сезон, 2025). Смотреть можно разве что для того, чтобы подсчитывать количество раз, когда ты воскликнешь "ну что за бред?!". А если серьезно, то лучше пройти мимо и не тратить свое время.

В качестве итогов 2025-го года из фильмов я бы выделил F1 (2025) и Маскарад (Mascarade, 2022), а из сериалов Бар "Один звонок" (первый сезон, 2023), Больница Питт (The Pitt, 2025), 13 клиническая. Начало (2024).

Отдельно бы отметил пару свежих глотков воздуха во вселенной "Хищника". Прежде всего полнометражный мультфильм Хищник: Убийца убийц (Predator: Killer of Killers, 2025). Но и кино Хищник: Планета смерти (Predator: Badlands, 2025) лично мне очень понравилось.

[work-n-life] Послесловие к уходящему году и поздравления с НГ

2025-12-31T11:24:00.000+03:00

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

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

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

В профессиональном плане, когда здоровье позволяло полноценно работать, все было достаточно ровно и рутинно, как и в 2024-ом: получаешь новую задачу, вникаешь, куришь бамбук, экспериментируешь, делаешь, тестируешь, доводишь до ума, получаешь новую задачу, вникаешь, куришь бамбук... И так снова и снова. Разве что местами сложность выполняемой работы несколько превышала мои возможности и мозги закипали от нагрузки. Очень надеюсь, что так продолжится и в 2026-ом.

С другой стороны, 2025-ый оказался все таким же безрадостным для наших собственных открытых продуктов. Два небольших релиза для SObjectizer и ничего нового в RESTinio 🙁 Но нельзя не вспомнить два знаковых события, связанных с SO-5: доклад Марко Арена на митапе в Болонье и использование SO-5 в проекте компании YADRO.

По поводу SObjectizer-а есть одна большая хотелка на 2026-й и было бы очень и очень здорово, если бы удалось воплотить её в жизнь.

В блог писал меньше, чем в предыдущие годы. Даже в самом тяжелом 2021-ом удалось написать на один пост больше. Отчасти это объясняется тем, что сейчас я гораздо чаще сиюминутные впечатления публикую в LinkedIn. В этом плане использую LinkedIn в качестве Twitter-а -- удобно зафиксировать какую-то эмоцию или сделать репост чего-то. Тогда как написание блог-поста требует времени и концентрации, поэтому на blogger-е публиковался меньше. Но старался не снижать качества. Чем, собственно, и собираюсь заниматься в следующем году. Так что если вы все еще находите для себя что-то интересное в моем блоге, то не переключайтесь 😉

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

Планы на будущий год опять очень простые: прожить его.

Только вот в 2025-ом воплотить их в жизнь оказалось не так-то просто. Надеюсь, в 2026-ом будет попроще. И, если это получится, то буду стараться делать что-то полезное и публиковать что-нибудь интересное. Как-то так.

Всем же читателям пожелаю здоровья, здоровья и еще раз здоровья в наступающем 2026-ом. Пусть ваш 2026-ой будет гораздо лучше моего 2025-го.

Ну и всем нам мирного неба над головой.

PS. Немного слукавил по поводу отсутствия чего-либо интересного вне работы: в этом году случилось 30-летие нашего выпуска из ГГУ. На вечер встречи мне прийти не удалось, но зато раскопал свои старые фотопленки со студенческих времен и оцифровал то, что на них еще осталось. Заглянуть в прошлое на несколько десятков лет назад -- это впечатляет. Вот, например, ваш покорный слуга собственной персоной в кузове трактора "на картошке" в октябре 1990-го года.

[prog.c++] Двадцать лет назад была опубликована первая статья о SObjectizer

2025-12-30T15:31:00.000+03:00

30-го декабря 2005-го года в печатном(!!!) номере журнала RSDN Magazine (ага, был такой) вышла статья SObjectizer: I Love This Game!. В ней впервые описывался SObjectizer-4 из которого в 2010-ом вырос и нынешний SObjectizer-5.

Сейчас самому очень интересно читать про SO-4.

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

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

Через некоторое время после публикации этой статьи исходные тексты SO-4 были размещены на SourceForge и SObjectizer перешел в категорию OpenSource проектов. Что и определило его дальнейшую судьбу. Ведь благодаря тому, что в 2006-ом открыли SO-4, в 2013-ом был открыт и SO-5. А это позволило нам продолжить работать над SO-5 и после ухода из компании Интервэйл, где SObjectizer появился. Не случись той первой статьи о SObjectizer, возможно и SO-4, и SO-5 так и остались бы внутренними проектами компании. И, скорее всего, тихо бы умерли с годами в связи закрытием проектов, в которых SObjectizer использовался.

Более того, не случись первой статьи о SO-4, возможно, никакого бы SO-5 и не появилось бы вовсе. В процессе обсуждения SObjectizer-а в Интернете (в первую очередь вспоминаются диалоги с Дмитрием Вьюковым) стало понятно, что SO-4 достиг своего потолка, что его возможности по развитию полностью исчерпаны, что нужно делать новую итерацию, оставив самое важное, но исправив допущенные ошибки.

На осмысление всего этого требовалось время. Но, в итоге, в 2010-ом разработка SO-5 стартовала. И, к счастью, продолжается до сих пор. Что вряд ли произошло бы без той самой "SObjectizer: I Love This Game!" в декабре 2005-го.

Пока писал эти строки поймал себя на том, что одной из причин, по которой SO-4 не вызвал интереса в 2005-ом, была роль C++ в тогдашнем ИТ. Прекрасно помню, как C++ тогда стремительно превращался из мейнстрима в маргинальный язык, который принято ругать и ни в коем случае нельзя брать для разработки.

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

Только 20 лет назад предлагали валить с C++ на Java и C#. А сейчас с C++ на Go или Rust. Но валить надо, хоть в этом есть какая-то стабильность 😏

Что уж поделать, реальность такова, что мы пишем код на C++, живем с недостатками C++ и делаем инструмент, упрощающий нам жизнь именно с C++. Работай мы на Java, C# или Rust-е, возможно, сделали бы что-то вроде SObjectizer-а и для этих языков. Но выглядело бы это точно иначе. А пока мы продолжаем программировать на C++, то и SObjectizer остается на C++ и для C++. Се ля ви.

Если же продолжить тему юбилеев (а ведь в 2025-ом исполнилось 15 лет пятому SObjectizer-у), то самим идеям, которые легли в основу сперва SCADA Objectizer, а затем и SObjectizer, уже лет тридцать. Если мне не изменяет склероз, то сформулированы они были осенью 1995-го года.

Дело было так. В октябре 1994-го меня и еще двух моих друзей-сокурсников пригласил работать в свой отдел в КБ Системного Программирования Аркадий Косарев. Как раз для того, чтобы нашими силами делать новую объектно-ориентированную SCADA-систему. И вот с осени 1994-го по весну 1995-ого мы будучи студентами пятого курса + еще один наш молодой коллега, Василий Гайдуков (он закончил наш же универ на год раньше), пытались родить какие-то идеи для будущей SCADA-системы. Без особого успеха, что было вполне ожидаемо.

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

Как именно рождались идеи SCADA Objectizer я уже не помню, но вспоминается, что большее влияние оказала книга "Объектно-ориентированный анализ: моделирование мира в состояниях" за авторством С.Шлеер и С.Меллор.

Не помню и когда именно появилось само название SCADA Objectizer. Почему-то кажется, что позже, году в 1997-ом, если не в 1998-ом. Но вот в том, что базовые принципы будущего SCADA Objectizer-а были сформулированы осенью 1995-го или зимой 1996-го практически уверен.

В общем, как-то очень уж долго я варюсь в этой теме агентов, асинхронно общающихся друг с другом посредством сообщений. Но, тем не менее, все еще love this game! Отличный все-таки был выбран заголовок для статьи 20 лет назад. До сих пор актуальный.

В Интернете все еще валяется руководство по программированию на SObjectizer-4 под скромным названием SObjectizer-4 Book 😲

[prog.c++] Компания YADRO использует SObjectizer в одном из своих проектов

2025-12-26T16:06:00.000+03:00

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

Подробностей у меня самого нет, т.к. все это происходило без моего участия. Люди просто взяли SObjectizer и сделали на нем то, что им было нужно. Может быть, если повезет, кто-то из участников проекта решится написать на Хабре или где-то еще о своих впечатлениях. Было бы здорово. В том числе и в плане PR-а для нашего открытого проекта.

Ну а пока это все, что получается рассказать.

[c++.flame] Желтушные заголовки: Microsoft собирается переписать весь Сишный и C++ный код на Rust!

2025-12-24T16:50:00.003+03:00

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

Настоящая шок-сенсация в статье на Хабре:

Microsoft планирует модернизировать свои крупнейшие кодовые базы и к концу десятилетия полностью исключить весь код на C/C++, заменив его на Rust.

Со ссылкой на источник на английском языке, который говорит о том же:

Microsoft is taking an impressive step in modernizing its biggest codebases and will eliminate all C/C++ code by the end of the decade, replacing it with Rust.

Для старых ~~упоротых~~ C++ников, вроде меня, новость из категории "А-А-А, мама, мы все умрем! Вот прям завтра помрем вааапще все!!!"

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

На самом деле некий инженер из Microsoft, работающий над экспериментальным проектом, запостил у себя в LinkedIn ссылку на вакансию в своей команде. Мол, ищем разработчика под амбициозный проект. И личной целью этого самого инженера является полная замена кода на Си и C++. Личной целью конкретного руководителя какого-то экспериментального проекта внутри Microsoft.

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

Бзик конкретного человека (я бы сказал, безумная вера в утопическое будущее) разогнали до планетарного масштаба.

Тьфу, срамота.

[prog.c++] Интересно, а какой код понятнее?

2025-12-02T16:15:00.000+03:00

В современном C++ одни и те же вещи можно сделать по разному.

Например, у нас есть список типов, для каждого из которых нужно сделать какое-то действие. Что-то вроде for_each-а, но для списка типов.

Можно сделать это вот так:

template<typename... Types>
void for_each_type_via_lambda(int arg) {
    const auto action = [arg]<typename T>() {
        std::cout << typeid(T).name() << " - " << arg << std::endl;
    };
    (action.template operator()<Types>(), ...);
}

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

А можно сделать более старым способом, без лямбды, но с помощью вспомогательной функции:

template<typename T>
void do_something(int arg) {
std::cout << typeid(T).name() << " - " << arg << std::endl;
}

template<typename... Types>
void for_each_type(int arg) {
(do_something<Types>(arg), ...);
}

Результат будет один и тот же. Но вот понятность двух этих вариантов лично для меня совершенно разная.

Интересно, а какой из вариантов более понятен для вас?

PS. Этот пример на wandbox "для поиграться".

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

2025-12-01T19:21:00.000+03:00

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

Фильмы

Хищник: Планета смерти (Predator: Badlands, 2025). Посмотрел с удовольствием, мне понравилось. Наверное, это лучшее, что сняли после второй части "Хищника".

Кто она? (The Artifice Girl, 2022). Мне понравилось. Но не-айтишникам следить за происходящим на экране может быть сложновато.

Операция "Наполеон" (Napóleonsskjölin, 2023). Это что-то вроде современного Индианы Джонса на минималках, бюджет там явно был мизерный. Но по итогу на удивление неплохо и вполне себе смотрибельно.

Геля (2025). Вполне смотрибельно. Не всё понял по сюжету, но фильм смешной.

Франкенштейн (Frankenstein, 2025). Отлично снятая сказка. Если такой жанр нравится, то смело можно смотреть.

Призрак на поле боя (Un fantasma en la batalla, 2025). По сюжету очень перекликается с испанским же Агент под прикрытием. Но "Призрак..." чуть более суровый и мрачный, как мне показалось. Не шедевр, но смотреть можно.

Святая ночь. Охотники на демонов (Georukhan bam: demon heonteoseu, 2025). Простенько, бюджетненько, но вполне себе смотрибельно. Однако, этот фильм, скорее всего, для очень узкой аудитории: для тех кому нравится корейское кино и, одновременно, кино про демонов и экзорцизм.

Разрушитель миров (Worldbreaker, 2025). В принципе, не самое плохое фэнтези для подростков. Но мне совершенно не хватило экшОна, а без экшОна повествование получилось пресным и затянутым.

Туман (2023). Снято красиво, да. Но это единственное, что есть хорошего в фильме. Сама рассказанная история выглядит каким-то бредом.

Укрытие номер один (Safe House, 2025). Очень бюджетно и очень тупо. Лучше пройти мимо этого фильма.

Сериалы

Константинополь (первый сезон, 2025). Разочарован. Ждал чего-то вроде современной версии фильма "Бег", но увидел что-то невнятное про борьбу вымышленных ОПГ в вымышленном псевдоисторическом антураже. Жаль потраченного времени.

Лихие (оба сезона, 2024-2025). Развязка просто говно говна. Поэтому не рекомендую тратить на это кино свое время.

Ночной экспресс (Nightsleeper, первый сезон, 2024). Купился на высокий рейтинг на Кинопоиске. Редкий маразм. Жаль потраченного времени.

[prog.c++] История с потреблением памяти из-за фрагментации хипа в mimalloc-е

2025-11-28T09:00:00.000+03:00

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

Что, собственно, до некоторых пор и происходило: по показаниям htop было видно, как сперва потребление памяти растет, затем резко падает.

Но в какой-то момент поведение изменилось: потребление памяти росло во время первичной обработки, потом уменьшалось, но уменьшалось не настолько, насколько ожидалось. Грубо говоря, раньше в пике съедали 1Gb, затем падали до 400Mb. Теперь же в пике съедаем 1Gb, но затем падаем всего до 600Mb.

Естественно, возникло ощущение, что где-то есть утечка. Но никакой утечки не нашли. Зато нашли явные следы фрагментации хипа.

Сразу извинения: я не уверен на 100%, что термин "фрагментация" здесь является точным. Но лучшего, увы, не придумал. Поэтому прошу гнилыми помидорами не бросаться.

В проекте в качестве дефолтного аллокатора используется mimalloc. Хвала его создателям, в API mimalloc-а есть средства для интроспекции содержимого хипа, что и позволило обнаружить эффект фрагментации.

Нужно сказать, что mimalloc спроектирован так, чтобы максимально избавиться от вероятности фрагментации (насколько это в принципе возможно для языков без compacting GC): он использует арены (areas) под объекты фиксированного размера. Так, объекты размером в 16 байт создаются в своей арене, объекты размером в 32 байта -- в своей, размером 48 байт -- в своей и т.д. Тем самым mimalloc частично избавляется от эффекта "дырок в сыре" -- когда суммарно свободной памяти много, но вся она рассредоточена в мелких фрагментах, чередующихся с занятыми фрагментами.

Выяснилось, что под контролем mimalloc-а оказываются буквально сотни арен для объектов размером 16 и 48 байта, на которых живых всего пара-тройка объектов, а все остальное пространство пустое. Но т.к. на этих аренах есть живые объекты, то mimalloc не может отдать выделенную под арены память обратно ОС. Поэтому ОС показывает, что приложение держит больше памяти, чем мы рассчитывали.

Почему же так произошло?

Первичная обработка данных при старте создает в динамической памяти множество объектов. Среди них огромный процент объектов как раз имеют размер 16 и 48 байт. Под них mimalloc динамически выделяет все новые и новые арены, запрашивая память у ОС.

При завершении обработки эти вспомогательные объекту удаляются. И ранее их удаление приводило к очистке тех арен mimalloc-а, в которых объекты размещались. По мере освобождения арен mimalloc возвращал память ОС. И по показаниям htop было видно, что потребление памяти приложением снижается.

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

Происходило это потому, что в процессе обработки начали создаваться не только "старые" объекты размером 16 и 48 байт, но и "новые" -- внутри этого самого нового контейнера. Только вот содержимое нового контейнера должно было остаться до конца работы программы, поэтому эти "новые" объекты не удалялись. В отличии от "старых" объектов, нужных только на время первичной обработки.

Получалось, что сплошным потоком создаются объекты размером, например, 48 байт. Львиная их часть относится к "старым" объектам, но иногда создаются и "новые". Пропорция приблизительно 500 "старых" объектов к одному "новому". Т.е. создали 500 "старых" объектов, затем один "новый", затем еще 500 "старых", затем еще один "новый" и т.д.

Физически это выглядит так, что на очередной арене mimalloc-а подряд размещается 500 "старых" объектов, за ними один "новый", затем еще 500 "старых", следом еще один "новый", затем арена заканчивается, начинается новая, на которой сперва идет 500 "старых" объектов, затем один "новый" и т.д.

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

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

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

Отсюда и возникала пропорция одного "нового" объекта (тот самый узел дерева) к пятистам "старым" объектам.

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

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

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

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

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

[prog.c++] Не нужно делать собственные специализации std::hash<std::pair<T,U>>

2025-11-24T07:43:00.000+03:00

Некоторое время назад я сам наткнулся на грабли при использовании библиотеки Folly. Мне потребовался std::hash для std::pair<int, some_my_type>, при этом std::hash для some_my_type у меня уже был. Поэтому я сделал специализацию std::hash для std::pair<int, some_my_type>, в которой использовал std::hash<some_my_type>. Собрал код, стал проверять и выяснил, что на некоторых тестовых сценариях происходит что-то странное. Начал разбираться и внезапно обнаружил, что мой std::hash для std::pair<int, some_my_type> не вызывается вообще.

Дело оказалось в том, что разработчики Folly подложили свинью своим пользователям и определили специализацию std::hash<std::pair<T, U>>. Чего делать по стандарту нельзя (за цитату из стандарта большое спасибо Константину Шарону):

• [namespace.std] (C++23 draft, §16.4.2.2/1):
The behavior of a C++ program is undefined if it adds declarations or definitions to namespace std or to a namespace within namespace std, unless otherwise specified.
• The only allowed exception is that you may specialize certain templates in std for user-defined types.

[unord.hash] (C++23 draft, §24.5.4.2/1): For all object types Key for which there exists a specialization std::hash, the program may define additional specializations of std::hash for user-defined types.

Тут особый упор нужно сделать на "for user-defined types", тогда как std::pair<T, U> -- это не user-defined type. Вот std::pair<int, some_my_type> -- это уже user-defined type и для него специализацию std::hash делать можно.

Об этом несколько месяцев назад я писал в LinkedIn. Но недавно на Reddit-е обнаружил ссылку на статью Simplify hashing in C++ в которой, ни много, ни мало, предлагается делать тоже самое, т.е. определять специализации std::hash для std::pair<T, U>.

Поскольку такое заблуждение существует, то приходится заострять на этом внимание. Поэтому, пожалуйста, не делайте собственные специализации std::hash<std::pair<T, U>>.

А если вы сомневаетесь в правильности того, о чем я говорю, то представьте себе ситуацию:

вы разрабатываете программу и определили какой-то собственный тип your_type;
вы захотели использовать your_type в качестве ключа в unordered_map и сделали для your_type специализацию std::hash;
затем вы захотели сэкономить себе время и силы и сделали специализацию std::hash для std::pair<T, U>. Теперь у вас автоматически поддерживается хеширование и для std::pair<int, your_type>, и для std::pair<your_type, int>, и прочих сочетаний your_type с другими типами, поддерживающими кэширование;
где-то в программе вы используете std::unordered_set<std::pair<int, your_type>>
все у вас работает нормально;
затем в один прекрасный момент вы подключаете в проект стороннюю библиотеку, в которую отдаете your_type, и которая использует std::pair<int, your_type> в качестве ключа в Folly::F14FastMap;
и тут оказывается, что у вас в проекте есть два определения для std::hash<std::pair<int, your_type>>

Поздравляю, у вас в коде Undefined Behaviour из-за нарушения one definition rule.

Реально хотите собственными руками подсаживать UB в код?

Разработчиков Folly понять можно: они делали Folly для своих собственных нужд и в их программах, разработанных под задачи Facebook-а, вряд ли могут встретиться другие специализации для std::hash. А то, что Folly применяют и за пределами Facebook-а, в том числе смешивая в одном проекте Folly с кучей других библиотек -- это не проблемы разработчиков Folly.

[prog.c++] SObjectizer-5 пятнадцать лет!

2025-11-21T13:34:00.002+03:00

Неумолимо быстро летит время и вот уже SObjectizer-5 исполняется пятнадцать лет.

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

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

Работа над SObjectizer в последние пять лет шла урывками.

В очередной раз повторюсь: непосредственно SObjectizer денег нам не приносит. Разве что создает некую репутацию и, как и RESTinio, приводит клиентов, которые увидев наши разработки предлагают нам тем или иным образом поучаствовать в решении их задач.

Т.е. зарабатывать на жизнь приходится не развивая SObjectizer за деньги внешних спонсоров, а трудясь на чужих проектах, зачастую никак с SObjectizer-ом (или RESTinio) не связанных. Что отнимает значительную часть времени и сил. А уже на том, что остается, делаются очередные версии SObjectizer-а.

Такова была ситуация в последние годы. Таковой она, судя по всему, и останется в будущем.

Поэтому бурного развития SObjectizer-а можно не ждать. Мы неторопливо и спокойно спускаемся с горы (если вы понимаете о чем я 😉)

Тем более что...

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

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

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

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

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

А за 5.6 последовали ветки 5.7 (январь 2020-го) и 5.8 (июнь 2023-го). Но их я сам рассматриваю как последовательное развитие ветки 5.6. К сожалению, без ломающих изменений не обошлось. Однако, они не настолько кардинальные, как это было при переходе от 5.5 к 5.6. В основном изменения между 5.7 и 5.8 в касались очень специфических внутренних интерфейсов SObjectizer-а и в гораздо меньшей степени затрагивали обычный пользовательский код.

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

Есть одна важная фраза, написанная пять лет назад:

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

Можно констатировать, что время подтвердило эти слова: SObjectizer-5 все еще развивается и насущной необходимости делать условный SObjectizer-6 на новых идеях пока что не видно.

Это значит, что из опыта SObjectizer-4 были сделаны более чем правильные выводы.

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

В 2021-ом году SObjectizer-ом заинтересовался Марко Арена, лидер сообщества Italian C++ Community. И со временем он внес очень существенный вклад как в популяризацию SObjectizer-а, так и в его развитие. Так, сперва мой коллега, Коля Гродзицкий, сделал доклад о SObjectizer-е на виртуальном митапе. Затем Марко опубликовал замечательную серию статей о SObjectizer-е. А недавно Марко еще и выступил с собственным докладом о SObjectizer-е. Это первый из известных мне докладов о SO-5, который был сделан кем-то не из команды разработки SObjectizer-а.

Но кроме серьезной работы по продвижению SObjectizer-а "в массы" Марко задал множество хороших вопросов и высказал ряд интересных соображений, на основании которых затем в SObjectizer были добавлены новые фичи.

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

Ну и самый важный лично для меня аспект, а именно ответ на вопрос "почему я все еще занимаюсь SObjectizer-ом?"

Пять лет назад я уже дал исчерпывающий ответ на этот вопрос. Но этот ответ был актуален на 2020-й год: главной (но не единственной) причиной было желание сделать из SObjectizer-а полноценный продукт за который не стыдно.

Это было сделано. За SObjectizer-5 уже давно не стыдно. И за прошедшее время, надеюсь, наша разработка стала только лучше.

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

Вероятно, действуют вот эти причины:

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

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

Состояние SObjectizer-а и его перспективы

Брать или не брать такой SObjectizer в работу?

Там все уже было сказано. Сказать лучше не получится. Надеюсь только, что сам факт развития SObjectizer-5 в течении 15 лет что-то да говорит.

Чем сейчас можно помочь SObjectizer-у?

На мой взгляд, сейчас, как и 5 лет назад, SObjectizer больше всего нуждается в двух вещах:

распространении информации о нем. Если вы попробовали SObjectizer и он вам понравился или не понравился, то найдите, пожалуйста, время и возможность поделиться этим в Интернете. Поверьте, даже коротенький пост из одного предложения в Twitter-е оказывается огромным подспорьем в нашей работе;
обратной связи: если вам что-то не понравилось в SObjectizer или чего-то не хватает, сообщите, пожалуйста, нам об этом. Мы не сможем добавить в SObjectizer то, о чем не знаем.

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

Добавлена возможность брать под контроль создание рабочих нитей в штатных диспетчерах SObjectizer-а: тыц.

В класс agent_t добавлен метод so_deactivate_agent: тыц. Затем в довесок был добавлен метод so_drop_all_subscriptions_and_filters: тыц.

Для агента теперь можно назначить собственный MPSC-mbox в качестве direct-mbox-а: тыц.

Теперь delivery filters можно устанавливать даже на MPSC-mbox-ы: тыц.

Серьезно изменился интерфейс abstract_message_box_t. Добавилось понятие delivery_mode для того, чтобы можно было понять из какого контекста сообщения отсылаются (например, если сообщение идет с нити таймера, то в этом случае нельзя блокировать отправителя сообщения). При этом теперь mbox-ам не нужно заниматься контролем message limits. Тыц.

Добавлено понятие message_sink-а. Теперь в качестве подписчика для mbox-а может выступать не только агент, но и вообще произвольна сущность, реализующая интерфейс abstract_message_sink: тыц.

Добавлена возможность регистрировать в SOEnv именованные mbox-ы, которые были созданы пользователем, а не SObjectizer-ом: тыц.

Сделаны шаги в сторону лучшего обеспечения noexcept-гарантий со стороны SObjectizer-а при выполнении дерегистрации кооперации: изменен интерфейс event_queue_t, добавлены диспетчеры nef_one_thread, nef_thread_pool: тыц.

В класс agent_t добавлены методы so_5::agent_t::so_this_agent_disp_binder() и so_5::agent_t::so_this_coop_disp_binder() чтобы можно было узнать, с какими диспетчерами агент связан: тыц.

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

Расширен набор инструментов для юнит-тестирования агентов: тыц и тыц, и тыц.

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

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