суббота, 9 апреля 2022 г.

[prog.flame] На тему понятности кода

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

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

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

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

Встречаю в коде функции длиной в 300+ строк вот такой вот фрагмент (все на чистой ламповой Сишечке):

четверг, 7 апреля 2022 г.

[prog.c++] Продолжение темы про передачу C++объектов через shared memory. Промежуточные выводы

Сама тема была обозначена здесь.

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

Т.е., допустим, у нас есть некий тип Data:

struct Data {
  int a_;
  long b_;
  short c_;
};

В процессе-продюсере мы используем placement new для размещения Data в shared memory:

auto * memory_block = allocate_block_in_shmem(sizeof(Data));
auto * d = new(memory_block) Data();
d->a_ = 0;
...

На стороне же процесса-консьюмера мы используем memcpy:

auto * memory_block = obtain_valid_pointer_to_block_in_shmem(...);
Data d;
std::memcpy(d, memory_block, sizeof(Data));
std::cout << d.a_ << std::endl; // Тут нет UB.

Очевидно, что таким способом через shared memory могут передаваться только trivially copyable объекты.

Это то, в чем я сейчас на 100% уверен (с поправкой на то, что могу и ошибаться).

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

среда, 6 апреля 2022 г.

[kubuntu] Мне кажется или в Kubuntu таки 20.04 заметно улучшился рендеринг шрифтов?

Только что обновил свой основной рабочий ноубук с Kubuntu 18.04 до 20.04. И мне показалось, что в 20.04 рендеринг шрифтов заметно улучшился. Текст на экране (14", FullHD) стал выглядеть более четким.

Это только мне так кажется или кто-то из читателей блога пересаживался на Ubuntu/Kubuntu 20.04 и наблюдал такой же эффект?

Заодно еще такой вопрос: если мне не изменяет склероз, то в этом апреле должна выйти следующая LTS для Ubuntu/Kubuntu, 22.04. Насколько разумно обновляться с 20.04 на 22.04 в течении месяца-двух после выхода 22.04? Может имеет смысл подождать полгодика-год?

А то я тут, похоже, на 18.04 слишком долго просидел, надо было, наверное, на 20.04 переходить пораньше. Но мешали старые воспоминания о Linux-ах, в которых было стремно обновляться до свежих релизов из-за сырости оных.

понедельник, 4 апреля 2022 г.

[wow] Wargaming сворачивает бизнесы в РФ и РБ, закрывает свою студию в Минске

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

Новость на русском на сайте sputnik: тыц.

Подозреваю, что рынок труда в РБ начнет тясти (если уже не, просто я тут закуклился в своей провинции, не имею представления как оно там, у центре-то).

Отдельно доставляет количество лайков на этой новости в LinkedIn (скриншот как раз оттуда). Доставляет, но не удивляет.