C++ *

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

Автор подробно разбирает архитектуру протокола, который сочетает асимметричную и симметричную криптографию. Описывается трехэтапный процесс «рукопожатия» (handshake) с использованием эллиптических кривых (X25519) для безопасного обмена ключами и обеспечения Perfect Forward Secrecy (PFS). Также объясняется выбор симметричного шифра ChaCha20-Poly1305 для быстрой и безопасной передачи данных и его преимущества перед AES‑GCM на устройствах без аппаратной поддержки.

Статья раскрывает детали реализации, включая структуру зашифрованных пакетов, защиту от replay‑атак с помощью счетчика сообщений и использование KDF для генерации сессионных ключей. Теоретические концепции подкрепляются наглядными примерами кода на C++. Эта статья будет интересна для тех, кто интересуется криптографией и любит создавать «велосипеды» в образовательных целях.

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

Что если есть архитектура, где этого узкого места нет? RISC-V предоставляет гетерогенность принципиально нового уровня, объединяя ключевые компоненты устройства на одном кристалле, что снимает одно из главные ограничений производительности в ML. Но одних процессоров здесь мало — нужна еще экосистема библиотек.

Привет! На связи Антон Полухин из Техплатформы Городских сервисов Яндекса. Сегодня я расскажу о ноябрьской встрече Международного комитета по стандартизации языка программирования C++, в которой принимал активное участие. Это была первая из встреч, связанных с «полировкой» C++26. Другими словами, новые фичи C++ пока не появятся — комитет должен только проработать замечания всех стран-участников, включая наши замечания от России.

Однако от плана немного отступили и втащили некоторые новинки как ответы на пожелания участников комитета: std::integer_sequence оброс новой функциональностью, а std::format научился в constexpr.

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

Можно использовать iperf3, но он про TCP и базовый UDP. Можно взять отдельные QUIC-библиотеки, но без визуализации и нагрузки. Можно написать кастомные симуляторы, но они не отражают реального поведения каналов. Хочешь проверить, как BBRv3 ведет себя на трассе Москва — Новосибирск? Пожалуйста, найди три сервера в разных дата-центрах, настрой netem, собери метрики вручную и надейся, что результаты будут воспроизводимы.

Продолжаем серию «C++, копаем вглубь». Цель этой серии — рассказать максимально подробно о разных особенностях языка, возможно довольно специфичных. Это девятая статья из серии, список предыдущих статей приведен в разделе 6. Серия ориентирована на программистов, имеющих определенный опыт работы на C++. Данная статья посвящена специальным функциям-членам.

В C++ жизненный цикл экземпляра класса/структуры/объединения (объект, представляемый в коде переменной) начинается с инициализации, то есть задания его начального состояния. Далее, почти всегда, объект копируется, выполняются присваивания или их перемещающие аналоги. Эти операции необходимы для работы функций, контейнеров, алгоритмов. Финальной точкой жизненного цикла объекта является его уничтожение. Именно для поддержки этих операций в C++ и предназначены специальные функции-члены.

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

Итак, попробуем рассказать о специальных функциях-членах максимально подробно.

Когда-то давным-давно (то есть до C++20) мы форматировали вывод либо по-старинке через printf, либо используя громоздкие стримы ввода-вывода из <iostream>. Оба подхода, мягко говоря, не очень. printf работал шустро и лаконично, но требовал строгого соответствия типов, забудешь правильный %d или %s в формате, и получишь неопределённое поведение вплоть до падения программы. Компиляторы иногда предупреждают о несоответствиях, но полностью проблему не решают (особенно если форматируемая строка не литерал). Кроме того, printf не умеет выводить пользовательские классы, только примитивы.

Сейчас ситуация изменилась. В C++20 завезли библиотеку <format>, современный подход к форматированию строк, сочетающий лаконичность printf с безопасностью iostream. Инструмент называется std::format и объявлен в заголовке <format>. По сути, это адаптация популярной библиотеки fmt.

Привет, я Данила Трусов, директор продукта «Инферит ИТМен».
Хочу рассказать, как мы в буквальном смысле переписали три года разработки за восемь месяцев — и почему этот переход оказался не просто технологическим апгрейдом, а шагом к полной независимости продукта.

Существует довольно много распространённых «мудростей» о разработке игр на C++, различных обрядах и видах магии. И как это часто бывает с подобными сакральными знаниями, при внимательном осмотре - у части действительно есть право на жизнь, часть можно отправить в Каирский музей отбирать славу у мумий, а часть вообще оказывается родом из чужой реальности, и работать как предполагалось отказывается. Но это не мешает некоторым компаниям относиться к таким советам как к скрижалям, бережно принесённым с великой горы совещаний. Новым сотрудникам их передают почти с торжественностью обряда посвящения: «Так делали наши предки, так делаем и мы».

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

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

Видимо по этой причине, одним мрачным осенним днем мне захотелось создать графическое приложение на современном C++ под.. классический Mac из 90х.

Краткое и доступное руководство по базовым алгоритмам на графах: BFS, DFS, топологической сортировке и алгоритму Дейкстры. Чёткие объяснения, примеры и код на C++ — для тех, кто хочет быстро и уверенно освоить фундамент графовых алгоритмов.

ESPHome позволяет создавать программы для микроконтроллеров (ESP32, ESP8266 и т. д.) посредством написания YAML файлов. Это значительно упрощает и ускоряет разработку. Внешние компоненты (external components) разрабатываются с использованием С/С++ и Python и могут быть использованы повторно, по аналогии с библиотеками. Внешние компоненты могут разрабатываться для сенсоров, кнопок, GUI-компонентов и т.д.; подключаться локально или из удаленных репозиториев.

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

Данная статья является вводной по графике в Direct2D, после неё вы узнаете что такое ресурсы зависимые от устройства и не зависимые. Научитесь выводить на экран любую сложную(2D) геометрию. Узнать теоретическую часть по выводу графики, что такое ID2D1Factory и остальные вводные вещи.

У каждого из нас на жестких дисках копятся терабайты контента. Фильмы, скачанные «про запас», архивы семейных видео, гигабайты музыки во FLAC, которую жалко удалять, и тысячи фотографий. Но есть проблема: потреблять этот контент локально — неудобно. Когда дома лежит большой медиа‑архив — фотографии за годы, фильмы, музыка, куча видео — начинаешь задумываться, что работать с этим напрямую через файловую систему совсем не удобно. Особенно в эпоху, когда интерфейсы крупных медиа‑сервисов настолько продуманы, что сами по себе стали стандартом UX.

Я поставил перед собой задачу: сделать полноценный мультимедийный сервер, который работает из одного .exe файла, не требует интернета, не требует настройки и предоставляет удобный интерфейс.

Задача Эдсгера Дейкстры о философах – великая задача великого программиста. Уж сколько лет, а она актуальна. Решая ее, прикасаешься к этому величию. И вот, перефразируя известное, «давно не было такого и вот опять», можно познакомиться с ее «новым прочтением» на Хабре[1].

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

Познакомился с проблемой обедающих философов – Dinning Philosopher Problem (DPP), я более двадцати лет тому назад (про DPP см. [2]). Результатом стала статья, в которой философы выполняли поставленную задачу, как минимум, не хуже, чем классические алгоритмы сортировок[3]. Позднее был сделан доклад на конференции по параллельным вычислениям в Саратове, где на суд научной общественности была предъявлена модель автоматных параллельных вычислений и пример ее приложения - задача Дейкстры[4].  

Замечание 1. В рамках обсуждения статьи на Хабре было проигнорировано  предложение поручить сортировку философам. Зря, конечно, т.к. надо же как-то убедиться, что предлагаемое решение работает хотя бы в первом приближении. К примеру, тот же DeepSeek, моментально выдавший свое решение DPP, так и не смог заставить их сортировать.

Не знаю, считается ли данная задача решенной, но то, с чем я знаком, по большей части беглое рассмотрение проблем, которые она отражает. У задачи есть теория, которая представлена монографией Хоара[5], или моделями сетей Петри у Питерсона[6] и В.Е. Котова[7] или другими подобными публикациям. Но, повторюсь, все это по большей части достаточно краткий анализ свойств модели и/или даже конкретного решения. Статья на Хабре из этой же серии. Все это ни как не окончательное решение описываемых ею проблем параллелизма. Правда, может, [авторами] вопрос так и не ставился, но все же ответ на него весьма желательно иметь.

Издание SelaNi опубликовало результат анализа утечки секретных документов DARPA, слитых в сеть в начале недели. В документах в основном финансовые отчёты и перечисления финансируемых программ, но также там оказались планы и отчёты по экспериментам и разработкам проведённым агентством за период с 2009 до 2025 год.

Отчёт 2010 года свидетельствует о том, что основной проблемой военной промышленности США стал найм программистов. Основные критические системы, такие как банки, были написаны на COBOL, а в военной сфере по директиве DoD 3405.2 использовался только язык программирования Ada. Оба языка постепенно потеряли носителей и к 2010 году стало понятно, что им нужно искать замену.

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

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

Вы когда-нибудь хотели взглянуть на свой код под новым углом? Например, увидеть, как бы выглядела ваша кодовая база, будь она городом? Звучит как что-то невероятное. Давайте вместе заглянем в город PVS-Studio и просмотрим, какие тайны он в себе хранит :).

CryEngine2 использовал класс собственный CString для реализации работы со строками и немного использовал строки из стандартной строковой библиотеки Windows. Насколько я помню, последняя версия CryEngine всё ещё использует те же самые CString, она кардинально поменялась внутри, но как дань истории название класса менять не стали, зато сильно расширили функционал. Я не на 100% уверен, применялся ли CString только в редакторе или в рантайме игры тоже, вы можете сами это посмотреть в исходниках, которые все еще доступны на гитхабе. Это один подход к работе со строками, довольно распространенный в мире игростроя - когда мы все нужное пишем сами, не оглядываясь... хотя, тут больше уместно слово поглядывая, на существующие реализации и утаскивая в проект все самое лучшее.

Есть и другой подход... Я работал в команде над некоторым проектом, который должен был выйти на консолях, и в какой‑то момент на проект пришел эффективный тимлид, который хорошо умел в красивые презентации, и продавил использование std::string из sdk. Все очень опытные программисты, синьоры и руководство важно кивали на совещании и согласились всё перевести на std::string… не такие уж они оказались опытные, как выяснилось. В итоге мы заменили большую часть CString на std::string. Не сказал бы, что это сильно повлияло на время компиляции — плюс‑минус минута к проекту, который собирается двадцать минут, особой погоды не делают, но это также превратило наш довольно понятный базовый код в запутанный кошмар. Возможно, для переносимости это было лучше, но ни наш проект, ни CryEngine2 Editor так и не были портированы ни на Linux, ни на какую‑либо другую платформу.

Прошло десять лет, я вижу ровно туже ситуацию на текущем проекте — новый тимлид решил перевести местный MySuperPupeString на std::string, уже предчувствуя «нижней чуйкой» последствия — запасаюсь попкорном и беру отпуск на следующий месяц после принятия решения. Но не это интересно, а то — какие вообще строки могут быть в вашем с++ коде.

Что такое код-гольф? Это соревнование, в котором надо решить задачу по программированию (как правило, несложную), используя наименьшее количество символов. Соревнование довольно известное. Можно поиграть, например, на одноимённом сайте, есть целая секция на CodinGame, иногда такие соревнования публикует kaggle, была такая секция на HackerRank (сейчас её я не нашёл).

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

Временами мы развлекаемся таким форматом. В какой-то момент на внутренних ивентах подняли свою платформу для соревнований, а потом она протекла и на внешние конференции.

Эта статья — смесь разбора задач и истории появления соревнования по код-гольфу на конференциях Яндекса.