C++ *

Мы выбрали 10 топ-хабрастатей за 10 лет, а вы выберите лучший HR-бренд

Будем краткими: в этом году блогу МойОфис на Хабре исполнилось 10 лет!
Мы собрали юбилейную подборку — выбрали по одной ключевой статье на каждый год. Это тексты, без которых, как говорится, нас невозможно представить, еще труднее – понять!

А вас просим оценить нас в ежегодном опросе Хабр/ЭКОПСИ. Это займёт всего 5–7 минут. Мы соберём важную обратную связь, а индустрия получит объективную картину IT-брендов в 2025 году.

В прошлом году я помог Дмитрию Свиридкину подготовить и опубликовать цикл из 12 статей "Путеводитель C++ программиста по неопределённому поведению". Теперь этот расширенный, доработанный и обобщённый материал доступен в виде печатной книги:

Экскурс в неопределенное поведение C++ / Д. О. Свиридкин, А. Н. Карпов, – СПб.: БХВ-Петербург, 2025. – 384 с. – (Профессиональное программирование)

ISBN 978-5-9775-2073-7

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

Книгу можно найти в offline и online магазинах.

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

• Сплошные плюсы. Клуб С++ разработчиков.

• Митап «Мир С++».

• И т.д. Узнать о подобных мероприятиях можно, например, в моём ТГ канале "Бестиарий программирования".

Приятного и вдумчивого чтения!

TypeScript и C++ в одном бинаре. Первый open source-проект от МойОфис

Команда МойОфис выложила в open source собственную разработку — компилятор tsnative. Это кроссплатформенный инструмент, который объединяет удобство TypeScript с производительностью C++ в одном приложении. Исходники — на GitHub под лицензией Apache 2.0.

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

AntiQ разделен на два самостоятельных компонента. Сейчас в open source опубликован только tsnative — главный модуль, в котором сосредоточена основная логика и заложены архитектурные принципы всей платформы.

Зачем это нужно?

tsnative — это кроссплатформенный компилятор, преобразующий TypeScript в нативный машинный код. Он обеспечивает бесшовную интеграцию с C++ без glue-кода или JavaScript-движков, объединяя удобство высокоуровневой разработки с производительностью системного кода. В результате вы получаете один бинарник, собранный из двух языков.

Как это работает:

• C++-функции помечаются TS_EXPORT;

• генерируются .d.ts-декларации для TS;

• TypeScript- и C++-код собираются через LLVM;

• на выходе — один исполняемый файл, без обёрток.

// math.cpp
#include "TS.h"
TS_EXPORT int add(int a, int b) {
return a + b;
}
// index.ts
console.log(add(2, 3)); // -> 5

// index.ts
console.log(add(2, 3)); // -> 5

Проект может быть интересен тем, кто:

• делает нативные приложения, но хочет писать часть логики на TS;

• ищет замену закрытым коммерческим компиляторам;

• любит ковыряться в сборке, кросс-компиляции и низкоуровневом коде.

Открытый код — не просто «выложили и забыли». Мы хотим, чтобы проектом пользовались, коммитили, обсуждали. Поэтому будем рады pull request’ам, issue и звёздочкам. Всё как обычно :)

Исходники на GitHub

Если у вас есть вопросы или комментарии, вы можете задать их в чате проекта: https://t.me/antiqmyoffice

Что ты сделал для хип-хопа IT-инфраструктуры в свои годы? Писал UEFI и BMC для высоконагруженного оборудования 

В YADRO есть распределенная команда, которая разрабатывает и сопровождает собственные программные реализации UEFI (BIOS) и BMC. Для самого разного оборудования — от серверов до телеком- и клиентского оборудования. 

Познакомиться с командой → 

Какие задачи выполняют в команде BIOS/BMC: 

• Реализуют программную поддержку новых аппаратных продуктов компании, определяют протоколы и методы взаимодействия между программными и аппаратными компонентами продуктов YADRO.

• Проводят верификацию микрокода и выполняют проверку прошивок микросхем всех продуктов компании. Выстраивают стратегию тестирования.

• Исследуют новые программные и аппаратные технологии для применения в продуктах. Рефакторят код для повышения производительности.

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

• Добавляют новые фичи и меняют существующие — от WebUI до политик управления аппаратными компонентами.

Команде нужно больше инженеров — разработчиков на С/C++, тестировщиков, автоматизаторов и техлидов. Знакомься с вакансиями на сайте и вовлекайся в трушные инженерные задачи на современном технологическом стеке. 

Есть для альтернатива Delphi в 2025 году для простых кроссплатформенных приложений?

Навеяно обсуждением статьи про Дельфи в 2025.

Q1: Если сейчас есть задача по-быстрому сбацать что то с формами под винду - какая есть альтернатива дельфи?

Q2: А если так же быстро накидать, только кроссплатформенное приложение и без зависимостей?

И мой ответ

A: Не находишь, что 3000$ за кроссплатформенный дизайнер форм слишком дорого? Даже за хороший.

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

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

С чем то я работал, с чем то нет, актуальные версии вживую не проверял.

1. GNOME Builder (ex.Anjuta). GTK multilang IDE

2. Cambalache (ex.Glade) - GTK form builder

3. Qt Creator

4. FLUID for FLTK

5. wxFormBuilder for wxWidgets 

6. Projucer for JUCE

7. Ultimate++ 

8. NetBeans GUI design tool for Java Swing 

9. TKproE (TCL/TK Programming Environment)

10. Lazarus

11. MSEide+MSEgui Pascal

12. GTK# Visual Designer MonoDevelop (retired)

13. Xamarin.Forms GTK Backend (discontinued for NET MAUI)

14. JavaFX Scene Builder

15. Pygubu Tkinter a GUI for Python

    Может еще что и забыл, либо не попалось на глаза.

Из чего состоит MeyerSAN — решение для имитации ошибок в СХД

Проект MeyerSAN — это программно-аппаратный комплекс на основе сервера VEGMAN. Комплекс имитирует неисправность SAS HDD и SSD и позволяет автоматически тестировать реакцию системы хранения данных на ошибки. Решение необходимо для тестирования и валидации работы подсистем, которые находятся в составе СХД и определяют проблемные диски. 

Как это работает: 

1. Мы подключаем сервер к системе хранения данных. 

2. С помощью ПО и драйверов заставляем СХД видеть сервер как диск или несколько дисков.

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

Задача MeyerSAN — эмулировать проблемы с дисками: задержки, ошибки, порчу данных и метаданных.

Архитектура MeyerSAN состоит из трех больших блоков: 

1. REST, так называемый MRSNMGMT. Позволяет конфигурировать систему в соответствии с пожеланиями.

2. MRSNLib. Cодержит бизнес-логику приложения: обработку и модификацию команд.

3. Драйверы низкого уровня. Они предоставляют нам механизмы транспорта и позволяют соответствовать всем протоколам.

Средний компонент, MRSNLib, команда разработчиков написала на современном С++ 23. Как именно инженерам удалось интегрировать новейший стандарт, а также паттерны объектно-ориентированного программирования в проект MeyerSAN, рассказывает один из создателей проекта Константин Крюков в новой статье.

Когда я был в 9 классе в 1985 году, в Киеве поставили заведовать компьютеризацией школьного образования человека по фамилии Долина, бывшего полковника танковых войск из Донецка. Сейчас я понимаю что Долина был голова. Он временно поставил компьютеры MSX Yamaha в физматшколу номер 145, а через неделю их забрал. Ясень пень, что десятки физматшкольников потянулись в его контору, которая располагалась через дорогу.

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

Если с мытием полов у всех было еще более-менее, то инструкции обламывались писать 95% пришедших. Осталось всего 4 человека - один из 145-й (это я), два из физмат-интерната (у них были свои Ямахи, но с монохромным экраном и ограниченным доступом) и еще один школьник из третьей физматшколы (забыл номер). Долина предоставил нам безлимитный доступ ко всем компьютерам, тонне софтвера и посодействовал посылке двоих из нас в Новосибирскую Летнюю Школу Юных программистов.

На Ямахах помимо Бейсика был MSX-DOS, три компилятора Си, два компилятора Паскаля (включая ранний Turbo Pascal), Z80 процессор, ассемблер и отладчики (в командной строке и оконный), видеопроцессор со спрайтами, интерпретатор Lisp, Nevada Fortran, интерпретатор подмножества Пролога и даже перенесенный из CP/M подмножество Ada.

Мы писали для Долины программы типа записи действий футболистов на стадионе в реальном времени, а также графические мультики на Бейсике, которые он показывал людям из киевской киностудии мультфильмов. Он также был популярен у нанятой им секретарши которая подходила к нему сзади и обнимала его за плечи, на что он говорил "ты создана чтобы любить мужчин". Короче один из ролевых фигур моего взросления.

После Долины я в 10 классе пошел в Киевский Институт Кибернетики, но это уже была другая история.

Cataclysm: Dark Days Ahead (2025) — как живёт и развивается roguelike, который до сих пор учит выживать

Игра без маркетинга. Без издателя. Без бюджета. Но с кодом, который живёт дольше многих ААА-проектов. Почему Cataclysm DDA всё ещё актуальна — и что из неё может почерпнуть разработчик?

📌 Что это вообще за игра?

Cataclysm: Dark Days Ahead (или просто CDDA) — roguelike-выживалка с открытым исходным кодом. Изначально создана в 2010-х, проект уже давно перерос статус инди-хобби. Вокруг игры сформировалась уникальная архитектура разработки, напоминающая open-source проекты вроде Godot или Blender.

При этом CDDA — это не просто «рогалик». Это огромный симулятор выживания, в котором учитывается всё: климат, диета, микроорганизмы, ткани, генетика, сила удара, источник света, запах, химия топлива, рефлексы NPC…
Она не для всех — но от неё сложно оторваться.

🧬 Почему она до сих пор развивается?

Проект жив благодаря:

• Cообществу разработчиков, регулярно вносящих правки на GitHub

• Модульной архитектуре — почти всё, кроме движка, вынесено в JSON

• Открытому патч-процессу: pull-request может отправить любой желающий

• Строгому CI — игра проверяется на стабильность при каждом изменении

CDDA — это не Unity и не Unreal. Но это отличный пример того, как жить без них. Игра написана на C++ с минимальной внешней зависимостью и на удивление гибкой логикой.

🧠 Архитектура и интересные решения

• 📁 JSON Everywhere: почти все предметы, существа, профессии, здания, сценарии, книги, мутанты и их поведение — вынесены в конфиги. Даже атакующие свойства NPC настраиваются без перекомпиляции.

• 🧪 Эволюция и симуляция: монстры «видят» запах, запоминают игрока, боятся огня, ищут пищу, воспринимают звуки и реагируют на источник света.

• 🔧 Модификации на лету: моддинг работает в реальном времени. Можно изменить структуру мутанта или добавить новую машину, не трогая движок.

• 🛠 Технический долг признан открыто: разработчики не скрывают костыли. В issues открыто обсуждаются недоработки, устаревшие решения и предложения по рефакторингу.

🎮 Почему стоит попробовать?

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

🤔 А если хочется поучаствовать?

• Репозиторий: github.com/CleverRaven/Cataclysm-DDA

• Discord-разработка: discord.gg/cataclysmdda

• Редактировать можно всё: от предметов и диалогов — до поведения монстров

• Написать мод — можно за вечер

💬 И всё же...

Что делает старый roguelike привлекательным даже в 2025 году?
Что заставляет людей править JSON-файлы, компилить на локальной машине, и устраивать «чистки баланса» спустя 10 лет после релиза?

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

Мой обзор на YouTube: https://www.youtube.com/live/B_IGiKw2BuQ
Дубликат на RuTube: https://rutube.ru/video/a91c9c71da3808af7381b87e10e5daca/

Давно не виделись! Надо исправлять. А поскольку у нас с вами лето, нельзя просто так взять и собраться — устраиваем митап для всех, кто связал свою жизнь с С++. Программа плотная:

18:00-19:00 Сбор гостей и welcome-кофе

19:00-19:30 Использование С++ библиотек при разработке прикладных решений в Astra Linux

19:45-20:15 C++ как производительный runtime для микросервисов: обсудим подход, при котором C++ усиливает Node.js, а Node.js ускоряет интерфейсную часть C++-систем.

20:15-20:45 Брейк на обсуждения

20:45-21:15 «Дайджест по нейросетям и их применению в IT» 

21:15-22:00 Холиварный сейшен с экспертами: С++ мертв или нет. Обсуждаем эффективные практики и методы использования С++ в задачах разработки и интеграции.

Встречаемся на Бауманская ул., 11, стр. 8 — около 10 минут от м. Бауманская или м. Красносельская.

Подробности и регистрация тут

Привет Хабр! Это мой первый пост, и я просто хотелось спросить, стоит ли уходить в Go? У меня есть небольшая база в программировании, делал сайты на реакт и ларавел, реализовывал бэкенд с Солид и паттернами, писал на нативном пхп файловые обменники и апи. Не много знаю базы данных соответственно, гит, докер. Сейчас засматриваюсь на Go, где то вычитал что мол крутая штука для бигтехов в России, а сам я студент и пока сижу на шее у родителей, но в следующем году я окончу к курс, и хочу где то месяца за 4-5 изучить все нужное в го и во всех других сопутствующих технологиях для разработки высоконагруженных приложений и микросервисов и всякого подобного. Стоит ли сворачивать на этот путь, или добить стек ларавел плюс вью? Немного боюсь, так как слышал что в го нужны уже 25 летние синьоры со стажем работы минимум в 20 лет, но и не хочется проторчать всю жизнь в челябинской галере на фуллстеке за 70 деревянных на руки.

Как нам обустроить С++

Помните старый анекдот? Учительница спрашивает: дети назовите слово на букву Ж. Вскакивает Вовочка и кричит: жоп@. Учительница говорит: Вовочка нет такого слова. Вовочка: как же так? жоп@ есть, а слова нет?

Программист С++ сейчас находится в положении Вовочки. Когда создать вложенный класс есть возможность

struct Foo {
	struct Bar {
	};
};

А написать опережающее описание мы не можем.

struct Foo;
struct Foo::Bar; // error: use of undefined type 'Foo'

Слова нет-с.

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

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

Я же со своей стороны тоже хочу внести посильный вклад и предлагаю название:

С❤︎❤︎

Привет хабр! Что-то долго я не писал статей здесь... Надеюсь вы прощаете меня.

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

Благодарю за внимание!

LLVM IR: что это такое?

Главной особенностью LLVM является промежуточное представление кода (англ. Intermediate Representation, IR), форма, которую использует LLVM для представления кода в компиляторе. LLVM IR был разработан для выполнения функций промежуточного анализа и преобразований внутри оптимизатора компилятора. Ее создание имело целью решение множества специализированных задач, включая поддержку легковесных оптимизаций среды выполнения, кроссфункциональные и межпроцедурные оптимизации, полный анализ программы и агрессивные реструктурирующие преобразования. Промежуточное представление кода определено как язык первого порядка с четкой семантикой.

IR (Intermediate Representation) в контексте LLVM — это промежуточное представление кода. Это низкоуровневое, независимое от платформы и типобезопасное представление программного кода, которое используется в качестве промежуточного языка между интерфейсной частью и серверной частью компилятора.

define i32 @add1(i32 %a, i32 %b) {
entry:
  %tmp1 = add i32 %a, %b
  ret i32 %tmp1
}

define i32 @add2(i32 %a, i32 %b) {
entry:
  %tmp1 = icmp eq i32 %a, 0
  br i1 %tmp1, label %done, label %recurse

recurse:
  %tmp2 = sub i32 %a, 1
  %tmp3 = add i32 %b, 1
  %tmp4 = call i32 @add2(i32 %tmp2, i32 %tmp3)
  ret i32 %tmp4

done:
  ret i32 %b
}

Этот код LLVM IR соответствует следующему коду на языке C, обеспечивающему возможность сложения целых чисел двумя разными способами:

unsigned add1(unsigned a, unsigned b) {
  return a+b;

}
// возможно не самый лучший способ сложения двух чисел
unsigned add2(unsigned a, unsigned b) {
  if (a == 0) return b;
  return add2(a-1, b+1);
}

Как видно из этого примера, LLVM IR — низкоуровневый RISC-подобный набор виртуальных инструкций. Как и настоящий набор инструкций RISC, он поддерживает линейные последовательности простых инструкций (сложение, вычитание, сравнение и ветвление). Эти инструкции имеют трехадресную форму. Это значит, что они берут некоторое количество входных данных и вычисляют результат в другом регистре. LLVM IR поддерживает метки и в целом выглядит как необычная форма языка ассемблера.

Строго говоря, промежуточное представление LLVM является четко определенным и единственным интерфейсом оптимизатора. Это означает, что всё, что необходимо знать, чтобы писать фронтенды для LLVM, это: что такое LLVM IR, как он работает и какие инварианты ему необходимы. Так как LLVM IR имеет текстовую форму, то имеет смысл создавать фронтенд, который выводит LLVM IR в виде текста, а затем отправляет его на оптимизатор и необходимый генератор кода при помощи каналов Unix.

Три дня, чтобы начать поддерживать инфраструктуру для базовых станций GSM/LTE

Это baseband-модуль (BBU) базовой станции, которую разработала команда Телеком в YADRO, и мы ищем DevOps-инженеров, которые к ней присоединятся. Таким специалистам нужно будет поддерживать процессы разработки (на С/С++, Go, Node.JS), развивать CI/CD и улучшать качество внутренних сервисов.

Узнать, как стать DevOps-инженером в YADRO → 

DevOps-специалистов разного уровня — от junior до senior — мы ждем по двум направлениям.

Infrastructure

Задача DevOps-инженера здесь — поддерживать бесперебойную работу инфраструктуры для разработки в телекоме. А это более 600 виртуальных машин, 20 информационных систем и десятков внутренних сервисов. Эта работа не просто про администрирование серверов, но и про автоматизацию работы и масштабирование инфраструктуры.

CI/CD

Специалисты по этому направлению организуют разработку и выпуск программно-аппаратных решений в сфере телекоммуникаций — с использованием Gitlab CI. Ежедневно они востребованы у более тысячи разработчиков и тестировщиков телекома. Цель DevOps-команды — сделать удобным процесс доставки изменений от разработчиков до продукта, а также постоянно улучшать и оптимизировать существующие решения, внедрять Observability для текущих продуктов, создавать новые инструменты.

Условия быстрого оффера

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

Больше про спринт-оффер и описания требований к специалистам — по ссылке.

Бета-тестирование: обновлённый парсер для анализа кода на языках C и C++

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

Уже больше года команда разработки PVS-Studio кропотливо работает над обновлением собственного парсера для анализа кода на языках C и C++. Это большое обновление, хоть и не видно для большинства пользователей. Оно служит фундаментом для дальнейших усовершенствований анализатора.

Отличная новость для пользователей Linux: по вашим многочисленным просьбам мы добавили возможность тестирования на Linux! Теперь пользователи обеих операционных систем (Windows и Linux) могут помочь нам в улучшении продукта. Если вы ещё не участвовали в тестировании, сейчас самое время присоединиться!

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

Как присоединиться к тестированию?

Просто заполните специальную форму на нашем сайте. В ответном письме вы получите подробную информацию о тестировании, инструкцию по установке тестовой версии и, при необходимости, временную лицензию на PVS-Studio.

Расскажите о своём опыте!

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

Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Mikhail Gelvikh. Beta testing: updated parser for C and C++ code analysis.

Тяжела и неказиста жизнь простого программиста статических анализаторов кода

Команда PVS-Studio, содействуя разработке методики испытаний статических анализаторов под руководством ФСТЭК, составляла некоторые синтетические тесты. Писать синтетические тесты сложнее, чем кажется, и с их достоверностью всегда масса нюансов. Я никогда не любил синтетические тесты и продолжаю их не любить. Но что делать, они тоже нужны, когда речь заходит о необходимости подтвердить, что в анализаторах реализован определённый набор технологий.

Даже зная и понимая нюансы составления синтетических тестов, мы всё равно наступили на собственные грабли! Переиграли сами себя :)

Есть составленные нами тесты, в которых в функцию srand или её аналог передаётся константное значение. Это приводит к тому, что функция rand каждый раз будет генерировать одинаковую последовательность псевдослучайных чисел. Такой код, согласно ГОСТ Р 71207-2024, п. 6.3.г, может являться ошибкой некорректного использования системных процедур и интерфейсов, связанных с обеспечением информационной безопасности (шифрования, разграничения доступа и пр.).

Когда тесты подготавливались в Compiler Explorer, всё работало: PVS-Studio выдавал предупреждение V1057. А сейчас, когда код мило и скромно лежит в файлах, не работает. На Compiler Explorer работает, а вне — нет. Магия. Уже собрались баг в анализаторе искать.

Ах нет, всё просто. Файлы с тестами называются test_err_*.cpp. И в детекторе срабатывает исключение N4: "Находимся в файле, содержащем в названии слова check/test/bench". Тьфу. Причём получается, что анализатор прав: это действительно тест, а не настоящий баг :) Вот оно, несовпадение реальности и синтетических проверок в действии. Выкрутимся как-нибудь, но решил описать, так как случай интересный.

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

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

Был рад поведать немного интересного из жизни разработчиков статических анализаторов кода. А если хочется послушать что-то ещё, приглашаю на подкаст "Статический анализ по серьёзному" с моим участием 27 мая в 19:00 по Москве.

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

Основные фичи:

• помимо шаблонизации файлов умеет шаблонизировать входной поток (stdin), используя переменные среды и результат выводить в выходной поток (stdout). Также как это делает envsubst

• поддерживает синтаксис Jinja2 и его основные фичи, такие как условия, циклы, переменные, инклюды, различные вспомогательные функции (например, из шаблона можно звать shell-скрипты)

• написана на C++ и собрана в статический бинарник x86 размером 350КБ без каких-либо дополнительных зависимостей, что позволяет её включать прямо в репозиторий и использовать в пайплайнах

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

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

Несколько примеров использования:

Простая подстановка переменной среды:

echo "Hello, {{ USER }}!" | muenvsubst

Шаблонизируем файл:

muenvsubst -i ./config.yml.j2 -o ./config.yml -d ./includes/

Использование переменных в шаблоне:

muenvsubst <<EOF
{%- set username = upper(USER) -%}
Hello, {{ username }}!
EOF

Использование флагов и условий:

USE_GREETER=yes muenvsubst << EOF
## if default(USE_GREETER, null) | toBool
Hello, {{ USER }}!
## else
Bye, {{ USER }}!
## endif
EOF

Использование циклов и разделение строки в список по символу:

USERS="John,Mark,Peter" muenvsubst << EOF
{%- for user in split(USERS,",") -%}
Hello, {{ user }}!
{%- endfor -%}
EOF

Использование инклюдов:

muenvsubst << EOF
## set USER="John"
## include "greeter.j2"
EOF

Файл инклюда greeter.j2:

Hello, {{ USER }}!

Gork-ушены-ли странности?
Пробуя вайбить Горкушей, обнаружил странные параллели с поведением Синего Кита.

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

2. похожие "чудачества в коде", пруф к сожалению привести не могу, он из реальной жизни, и не гуглится, но всё подобное, обычно делается простым и понятным способом, создаётся структура, в которой описывается сколько бит что означает, и вместо разбора пакета, он просто рассматривается через эту структуру и вообще удобненько. Gorkуше был предоставлен пример кода, в котором именно так всё было сделано, и он этим даже воспользовался пару раз, но потом, таки переписал, устроив программный разбор пакета битовыми операциями, и конечно-же криво на столько, что ошибки самостоятельно исправить был уже не в силах, ни за сколько итераций. Что самое поразительное, абсолютно аналогичное поведения я наблюдал у Синего Кита несколько дней назад, вот прямо такой-же код, и такой-же косячный. Логично предположить что он был откуда-то сдёрнут, но нет, ничего подобного не гуглится, да и вообще может-ли такой изврат человеку в голову придти?

3. Я люблю Кита за сравнительную трезвость, позволяющую куда-то его запрягать даже по делу, у Горкуши с этим к стати хуже но, тупят они поразительно похожим образом.
Давеча попросил сделать демона общающегося с железом и что-то шарящего в мемори для других процессов. Read only вестимо, об этом было прямо сказано в промпте, но эти "двое из ларца" мьютиксов туда намутили, поразительно похожим образом!
И ладно-бы это был-бы какой-то пример из книжки переписанный на 100500 сайтах, но нет, там и косяки одинаковые, и по поводу мьютиксов на каждом заборе популярно написано, что в таких ситуациях "скрипач не нужен, родной"...

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

Я начал мучить Горкушу ещё в X использовал преимущественно для самери поиска, а тут он вдруг резко так поумнел перед открытием, демонстрируя сходное с синим китом поведение, вот прямо в деталях. Так что не знаю прямо что и думать ;-)

PS. Протестировал профессионального Джимми 2.5, и кое-что из грядущего, слава Богам! Он действительно с виду более профессиональный НО, без образца проблему не решает, хотя это и ожидаемо, там где осмысленная архитектурная многоходовочка требуется...
...но в отличии от от Кита и Горкуши, Джимми дали мне ссылку на ту отраву, которой они все походу обожрались. Ok это отрава, бывает, но непонятно всё-же, с какого, если в сети есть большое количество годных примеров, берётся один, но гадкий? И как-же так вышло, что его сожрали все, такие разные ;-)

Работаем со свертками в PyTorch с помощью библиотеки CUTLASS и алгоритма Implicit GEMM

Библиотека CUTLASS — это набор C++ шаблонов для реализации высокопроизводительного GEMM в коде. Она предоставляет структурные блоки, из которых можно собрать или просто вызвать операцию GEMM. Поддерживает вычисление смешанной точности, использование TensorCores и других примитивов, доступных для быстрого вычисления. В отличие от cuBLAS, это open source-библиотека. Ее относительно просто интегрироватьь и модифицировать под свои задачи. 

Подход основан на тайлинге — разбиении задачи на мелкие подзадачи и распараллеливании. Как устроен процесс работы:

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

• Затем используются примитивы для переноса этих данных в shared-память, где происходит тайлинг на этом уровне.

• После выполняется работа на уровне варпов и регистров с использованием TensorCores или CUDA Cores. 

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

Библиотека предоставляет различные уровни специализации и конфигурирования: Device-level, Kernel-level, Block-level, warp, Instruction. Весь API представлен в виде шаблонов, из которых можно набирать те типы, которые потом инстанцируются для реализации нужного тайлинга. 

Какие еще инструменты могут расширить функциональность PyTorch для работы с большими свертками? Как выбрать алгоритм, подходящий для обучения моделей? Узнаете из статьи →

Я тут опубликовал библиотеку для программирования в парадигме потоков данных (dataflow) на микроконтроллерах: https://github.com/Zubax/ramen

Она чрезвычайно проста (один заголовочный файл) и работает на любой платформе без портирования.

Простейший пример --- сумматор:

               ┌────────┐
       (float) │ Summer │ (float)
 in_a ◄────────┤        │◄──────── out_sum
               │        │
       (float) │        │
 in_b ◄────────┤        │
               └────────┘

struct Summer
{
    ramen::Puller<float> in_a;
    ramen::Puller<float> in_b;
    ramen::Pullable<float> out_sum = [this](float& out) { out = *in_a + *in_b; };
};

Больше примеров, а также объяснение зачем это нужно при наличии альтернатив, по ссылке. Всем спасибо.