Тем кто собирает что-то под windows и задумался о версионировании сборочного окружения.

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

Версии окружения поднимаются, само окружение усложняется, требование команд к окружению растут и расходятся. Как тут всем угодить?

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

Многие разработчики привыкли везде ставить if-проверки, даже для условий, гарантированных кодом. Зачем проверять то, что не может нарушиться? Такие проверки создают шум в коде и мусор в релизе. Assert решает эту проблему: документирует допущения и исчезает из финальной сборки. В статье покажу все преимущества assert'ов и предостерегу от подводных камней их использования.

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

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

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

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

Так и появился данный проект, доступный в нашем публичном репозитории, реализованный на С++11.

Неопределённое поведение (Undefined Behavior, UB) в C и C++ — одна из причин, по которым разработчики всё чаще ищут языки с полностью определённой семантикой. Одним из самых коварных UB является unaligned access, с точки зрения стандарта C это, например, когда происходит попытка разыменовать указатель как uint32_t, а значение указателя (адрес) не кратно четырём. Один из частых сценариев использования, приводящих к такому UB - получение данных по сети и их интерпретация как чисел.

Сравнение PyBind11 vs ctypes

В принципе, можно вызывать C++ из Python двумя способами: при помощи библиотеки PyBind11 для C++, которая готовит модуль Python, либо при помощи пакета cytpes для Python, который предоставляет доступ к скомпилированной разделяемой библиотеке. Работая с PyBind11, не составляет труда совместно использовать множество типов данных, в то время как ctypes — это гораздо более низкоуровневое решение в стиле C.

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

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

QapDSL — декларативное описание AST и парсеров для C++

QapDSL — это специализированный язык (DSL), который позволяет описывать абстрактные синтаксические деревья (AST) и правила их разбора для языков программирования, прежде всего C++. Такая формализация помогает автоматизировать построение парсеров, генерацию кода, анализ исходников и даже рефакторинг.

Зачем нужен QapDSL?

• Компактно и наглядно описывать структуру и грамматику языка.
• Автоматически генерировать C++-структуры, парсеры, сериализаторы и визиторы.
• Ускорять эксперименты с языками, создавая прототипы компиляторов и анализаторов.
• Упрощать анализ и рефакторинг сложных языков, в т.ч. C++.

Пример QapDSL-описания

Рассмотрим, как описывается объявление класса C++ на QapDSL:

t_class{
  string keyword;
  t_sep sep0;
  string name;
  t_sep sep1;
  TAutoPtr<t_parents> parents;
  t_sep sep2;
  TAutoPtr<t_class_body> body;
  t_sep sep3;
  {
    M+=go_any_str_from_vec(keyword,split("struct,class,union",","));
    O+=go_auto(sep0);
    M+=go_str<t_name>(name);
    O+=go_auto(sep1);
    O+=go_auto(parents);
    O+=go_auto(sep2);
    O+=go_auto(body);
    O+=go_auto(sep3);
    M+=go_const(";");
  }
}

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

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

В этом HowTo мы рассмотрим подготовку пакетов vcpkg для использования в двоичном виде.

В качестве "подопытных кроликов" будут выступать Qt6, QCustomPlotи я.

Spoiler: с QCustomPlot придется немного пострадать, но обычно все проще.

TLDR: vcpkg export

Привет, Хабр! В этой статье я поделюсь своим опытом создания утилит в Unreal Engine, которые автоматизируют процесс генерации Actor Blueprint и Data Asset. Эти утилиты значительно упрощают работу дизайнерам уровней, помогая сократить время на рутинные задачи и минимизировать ошибки, а также могут быть полезны в широком спектре задач, связанных с разработкой.

Мы рассмотрим, как использовать Editor Utility Widgets на практике, чтобы упростить работу в редакторе. Основная часть будет выполнена в Blueprint, но для решения отдельных задач нам также понадобятся функции на C++. Помимо этого, я расскажу о важных аспектах работы с Asset Registry, фабриками ассетов и Subobject Data Subsystem.

Мне показалась очень интересной тема открытая в недавней статье

Собрал в одном большом гайде всё, что хотел бы знать, когда изучал язык C

 Во вступлении там написано:

"Очевидный факт: язык C — это основа большого количества современных экосистем программирования. Он обеспечивает фундамент многих операционных систем, базовых библиотек и системных инструментов."

Мне кажется полезно все таки обозначить в каком смысле язык C — это основа, и чем он обеспечивает фундамент. Я рад что имею возможность сформулировать что-то в данном направлении не со слов иностранного авторитета, а не базе собственного опыта который, тем не менее, формировался на основе анализа-применения действующих решений-теорий сформулированных во многом иностранными специалистами, но надеюсь с примесью собственной креативности в какой-то степени. Ну и хочется озвучить свой ответ на вопрос: "Когда C — идеальный выбор?", может в интерпретации: "А бывает ли язык Си идеальным выбором?"

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

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

Хочешь попробовать интеллектуальный спорт, где за пять часов нужно решить несколько задач и обойти соперников по скорости мышления? Спортивное программирование даёт не только адреналин соревнований, но и реальный буст к учёбе, поступлению и карьере — от первых олимпиад в школе до участия в ICPC и стажировок в IT-компаниях.

Введение

Обучающая программа «L'école» (см. мою статью: «Роль данных при изучении иностранного языка» – https://habr.com/ru/articles/930868/ ) предназначена для освоения иностранного языка по методу: «Запоминание руками + интерактивный звук + чтение по слогам + буквальный контекстный перевод». Саму программу и демо-данные к ней, на разных языках, можно непосредственно скачать из: https://disk.yandex.ru/d/5yjYP4JP1aVnIw .

И, если с обучающей программой, более-менее, всё понятно, то по данным (компьютерным урокам) остаются некоторые вопросы.

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

Как известно, изучение иностранного языка предполагает четыре навыка:

1. Понимание письменной речи.

2. Понимание устной речи.

3. Умение писать.

4. Умение говорить.

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

1. Звук и

2. Текст.

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

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

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

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

Всем привет, я разработчик игр на Unreal Engine 5, долгое время я занимался изучением игрового движка, созданием плагинов на FAB и теперь готов показать вам свой проект!

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

Статья посвящена очереди сообщений окна в Windows. Рассматриваются все действия с нею. Статья предназначена в основном для новичков в DirectX & Direct2D.

Я работаю в одном крупном российском банке, где занимаюсь разработкой распределённых систем. За последние несколько лет наша архитектура заметно усложнилась — часть сервисов работает в OpenShift, часть на виртуалках, а кое-что до сих пор крутится на «железе».

Основная боль заключалась в том, что у нас не было единой системы мониторинга. Метрики мы собирали из разных источников: где-то стоял Prometheus, где-то — Zabbix, в Kafka писали свои дашборды, а для C++ приложений вообще не было нормального мониторинга. Каждый инцидент превращался в расследование: мы переключались между тремя-четырьмя консолями, сверяли логи, писали временные скрипты для выгрузки метрик. В среднем на поиск корневой причины (root cause analysis) у нас уходило от нескольких часов до пары дней.

Я всегда считал, что взлом — это магия адресов и байтов. А потом я написал десять строчек на C и понял, что настоящая магия — это защиты компилятора и ОС. В этой статье я сознательно построю крохотный уязвимый пример, добьюсь управляемого падения (это и будет мой «эксплойт»), а затем превращу баг в безопасный и быстрый код. Ни одного шага против чужих систем — только локальная лаборатория и гигиена памяти.

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

Сегодня мы рассмотрим без преувеличений один из самых недооценённых алгоритмов стандартной библиотеки — std::search. Разберёмся, как он устроен, где реально экономит процессорные тики, а где лучше заменить его на что-то иное.