C++ *

История концептов в C++ – один из самых показательных примеров того, как язык развивается не линейно, а через десятилетия экспериментов, откатов и переосмыслений. Первые идеи, которые мы сегодня называем концептами, появились ещё в конце 1990-х, когда стало очевидно, что шаблоны C++ имеют колоссальную выразительность, но практически не дают средств для описания намерений программиста. Шаблон можно было инстанцировать почти с любым типом, но ошибка проявлялась либо в виде километров сообщений компилятора, либо в виде неожиданного поведения в рантайме. Уже тогда Страуструп сформулировал проблему как «отсутствие контрактов для шаблонов», когда программист знает, что от типа требуется оператор + или ==, но язык этого не выражает.

Ранние предложения концептов были чрезвычайно амбициозными и стремились описывать не только синтаксис, но и семантику. Например, концепт EqualityComparable должен был означать не просто наличие operator==, но и выполнение математических свойств эквивалентности: рефлексивности, симметричности и транзитивности. Аналогично, концепты для упорядоченных типов предполагали строгую слабую упорядоченность, а для итераторов корректное поведение при многократном проходе. Это отражало академический взгляд на обобщённое программирование, сильно вдохновленный функциональными языками и работами Степанова.

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

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

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

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

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

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

Существует ли хотя бы теоретическая возможность защититься от ошибок переполнения стека и сделать из нее обычную ошибку (исключение), которую можно поймать (обработать) в самом приложении, чтобы была возможность продолжить выполнение программы без боязни последующей ошибки сегментации (segmentation fault) или повреждения стека (stack smashing)?

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

Есть магия: взять число, разделить на ничто, умножить на ничто — и получить исходное. Не иллюзия, а математика уровней. Paradox библиотека — проводник в мир, где ноль бесконечно глубок, бесконечность структурирована, а запретные операции ведут не к краху, а к новым измерениям. Заклинание на C++ прилагается.

C++ — язык с долгой памятью. В нём до сих пор живут идиомы и приёмы, которые когда-то спасали разработчиков, а сегодня нередко мешают писать безопасный, быстрый и поддерживаемый код. Мы продолжаем использовать макросы, CRTP или iostream «по привычке», не всегда задумываясь о цене — сложности поддержки, скрытых багах, просадках производительности и времени команды. Разобраться, что в современном C++ действительно стоит брать в прод, а что пора оставить в прошлом, — важная задача для инженера, который не хочет тащить legacy в 2026 год.

Привет, Хабр! Недавно мы запустили шоу «АйТир Лист». В каждом выпуске берём одну тему из мира разработки и раскладываем её по тир-листу — от FAIL до GOD. В первом выпуске разбирали open source для фронтенда, а во втором выпуске — обсудим непростую тему фич и идиом С++.

Приглашённые эксперты — Антон Полухин, эксперт-разработчик C++ платформы городских сервисов Яндекса, и Даниил Черепанов, архитектор редакторов МойОфис.

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

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

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

В общем «не стреляйте в музыканта, он играет как может».

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

И попытался кратко описать основные моменты программы.

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

Таким образом, если вас интересуют общие проблемы параллельных процессов, то в этой и в последующих статьях на примере логических процессов мы их и рассмотрим. Терминологически мы будем придерживаться словаря по вычислительной технике под редакцией В.Иллингоута[1].  Но это может быть учебная литература, подобная [2], научная литература, как монография  [3], или научно-популярные книги типа [4, 5].

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

У меня сформировался свой вариант модели конечного автомата  (КА), который далее будет основным. Данная модель, во-первых, очень близка к классической форме. А это важно, т.к. позволяет использовать теорию почти без исключений. А, во-вторых,  она удобна для практики программирования, допуская эффективную ее реализацию.  Более детально все эти вопросы освещены в статье [6].

В настоящее время многоядерные процессоры с гетерогенными архитектурами, в которых сочетаются ядра с различной производительностью, становятся всё более и более распространенными. Если ещё пару лет назад такие архитектуры были в основном распространены в мобильном сегменте (см. ARM BIG.little), то с анонсом в 2022 году компанией Intel процессоров 12-го поколения линейки Intel Core, такие процессоры стали распространяться в сегменте десктопов и рабочих станций. Однако, до сих пор остается открытым вопрос — необходимо ли каким‑то специальным образом учитывать особенности данных архитектур для достижения максимальной многопоточной производительности?

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

Автомат — это карусель, на каждой позиции выполняется операция, затем поворот и все повторяется.

Работу автомата можно представить как множество параллельных процессов. Как же программно смоделировать множество параллельно работающих процессов?

Рассмотрим две проблемы при изучении иностранного языка. Это освоение грамматики и увеличение словарного запаса. Они не единственные, но важные. Про способы погружения в грамматику, на языке оригинала, можно прочитать в моей статье: «Уроки французского и пересоздание данных для изучения иностранного языка с помощью обучающей программы «L'école»», в https://habr.com/ru/articles/972594/ .

Там идея простая. Мы берем хороший учебник на языке оригинала, разбиваем текст на короткие смысловые фразы, снабжаем их фонетическим слогоделением и буквальным контекстным переводом (БКП). Затем, озвучиваем данные, например, с помощью TTS, для, в данном случае, обучающей программы «L'école» и создаем двуязычные html-тексты с транскрипцией (фонетическим слогоделение) или, другими словами, небольшую книгу в формате html.

Идея изучения грамматики основана на двух принципах:

– Мы читаем, громко, вслух фонетическую транскрипцию (предварительно осваиваем фонетический алфавит с помощью представленных уроков) и смотрим подстрочный перевод. Это для html-книг. А при работе в обучающей программе, мы можем, при желании, еще набирать текст руками (используя метод «запоминание руками», в режиме «Конспект»), слушать и проговаривать вслед интерактивную озвучку. При этом, не обязательно даже стремиться запоминать текст, при наборе его руками и повторении озвученной речи, уроки запоминаются «сами собой», особенно, если к ним периодически возвращаться.

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

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

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

С введением концептов и ограничений (requires) язык получил возможность управлять этой сложностью на уровне интерфейса. Вместо того чтобы надеяться на магию перегрузки и изощрённые трюки вроде SFINAE, мы теперь можем прямо выражать намерения: какие свойства должен иметь тип, чтобы функция или шаблон были корректны, что позволило перейти от «магии разрешения перегрузок» к декларативному описанию требований к типам.

Давайте теперь поговорим о том, что именно делают ограничения (requires) в современном C++ и почему появление этого механизма стало таким важным шагом в развитии шаблоннов. Тут надо сделать немного шаг в сторону и вспомнить, что исторически шаблоны в C++ были мощным, но довольно опасным инструментом, еще одним языком в языке, на котором можно было сделать почти всё, было бы желание. В итоге компилятор позволял подставить или подхачить любой тип, а проверка того, «подходит ли он на самом деле», откладывалась до момента инстанцирования, что нередко приводило к ошибке далеко от места вызова, а сообщение о непосредственном месте ошибки превращалось в многостраничный отчёт о внутренней кухне компилятора и как он работает с шаблонами. requires меняют эту модель, позволяя описывать ожидания от типа явно и прямо в объявлении функции или класса.

Привет, Хабр!

Пожалуй, одним из первых устройств, которые подключаются к умному дому (конечно, после модуля управления освещением), является домашняя метеостанция. Вот и мне на новом месте и в новом умном доме потребовалось реализовать данное устройство. Но есть одна проблема: находясь вдалеке от своей домашней лаборатории, я имею минимальный набор инструментов и лишен таких благ цивилизации, как лазерный мини-ЧПУ для изготовления плат и 3D-принтер. Поэтому для реализации проекта будем работать по старинке, в режиме жесткого DIY-хардкора (или «Очумелых ручек»). Впереди много картинок и термоклея, так что включайте ваши паяльники и поехали!

Генерируем лабиринт на гексагональной сетке Uber H3 и ищем путь с помощью двунаправленного A* — всё это на Qt 6 с визуализацией на реальной карте

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

Вычисление обратной матрицы, а именно, вычисление алгебраических дополнений и определителя матрицы займёт большое количество машинных ресурсов при квадратной матрицы высокого порядка. В статье описывается решение и приводятся результаты обращения квадратной матрицы методом решения системы AX = E, где A, X, E - квадратные матрицы порядка n, X - обратная A матрица, E - единичная матрица, и методом LU декомпозиции.

Привет, Хабр!

Так уж сложилось, что 99% устройств моего «умного дома» были спроектированы и собраны самостоятельно — что тут поделать, каждый развлекается как может. Об одном из таких устройств я писал ранее, а именно — о модуле управления освещением с радарным датчиком HLK-LD2402. И в соответствии с жизненным циклом отладки, а также процессом эксплуатации устройства назрела необходимость в программных улучшениях, о которых я постараюсь коротко рассказать в этой статье.

Прототип DIY tRNS: архитектура, генерация сигнала (100–640 Гц hf-tRNS), VCCS на Howland Current Pump, отображение метрик сигнала в процессе работы, репозиторий с кодом и выводы.

Как я собрал актуальный LLVM со всеми инструментами (Clang, LLD, LLDB, clang-extra-tools) и всеми нужными для автономной работы рантаймами (libc++, libc++abi,libinwind,compiler-rt,UCRT) нативно под Windows. В этой статье я расскажу о своем 4-месячном пути: от накоплений со школьных обедов на первый ПК до борьбы с линковкой библиотек и поиска фиксов в экспериментальной ветке LLVM 22. История о том, почему я выбрал путь «чистого Upstream» и как заставил это всё работать в 15 лет.