C++ *

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

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

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

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; };
};

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

Приветствую.

Я пишу облегчённую версию SDL3, с поддержкой старых систем. Проект решил назвать SDL3Lite. Проект пишу на C++ 98, но наружу торчит совместимый С API. Я хочу реализовать базовый функционал, поэтому вполне реально довести проект до конца. Главная идея проекта это сохранить совместимость с оригинальным C API SDL3. В идеале это конечно на уровне бинарной совместимости. Код единожды написанный должен собираться без изменений для всех поддерживаемых систем.

Сейчас работает рендер на OpenGL 1.2, добавляю версию software для старых систем без поддержки аппаратного ускорения. Также планирую добавить и поддержку vulkan. В репе есть скриншоты с выводом графики.

На данный момент поддерживается windows 95 и выше, linux начиная с Debian 3.

В будущих версиях планирую добавить поддержу windows 3.1 и ms-dos.

Рад буду советам, критике и предложениям.

YetiVM - встраиваемая виртуальная машина для RISC-V(VM-as-Library)

Для скачивания доступна YetiVM - встраиваемый эмулятор RISC-V.
На данный момент поддерживаются rv32i и rv32m.

Есть интеграция сriscv-non-isa/riscv-arch-test

Сам проект написан на C++20 и распространяется под лицензией MIT

Работаю в большом проекте состоящем из более чем сотни динамически подгружаемых библиотек. OracleLinux, QtCreator, Qt, C++. Испытывал большие неудобства при загрузке приложения в режиме отладки с большим количеством точек останова (на 10 штуках старт с 30 секунд увеличивался до 2 минут). Казалось бы очевидное, но закономерность замедления обнаружилась не сразу.

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

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

Возможно, я озвучил очевидность. Но мне, работая в данном окружении и в большой команде достаточно давно, это озарение снизошло не сразу. Я и не сильно боролся с этим до недавних пор, сильное замедление произошло не так давно при переходе с Qt4 на Qt5 (у нас вынужденное legacy).

Быстрое трудоустройство в YADRO для разработчиков на С++

У нас стартовал SPRINT OFFER в команду разработки телеком-оборудования. Для «плюсовиков» это возможность получить предложение о работе всего за несколько дней. Если хотите пропустить долгие этапы собеседований, отправляйте заявку до 9 марта. 

Как все происходит

1. Подаете заявку — мы оперативно рассматриваем анкеты.

2. Проходите HR-скрининг и техническое интервью — без недель ожидания между этапами.

3. Получаете оффер — если все этапы успешно пройдены, предложение будет у вас в течение 3 дней.

Где предстоит работать 

Дивизион телекома создает решения для мобильных сетей. Инженеры разрабатывают базовые станции GSM/LTE, полный стек телекоммуникационных протоколов, а также системы управления и мониторинга. Большую часть кода разработчики пишут на C++. В зависимости от задачи они используют как современные возможности C++20, так и низкоуровневые оптимизации для повышения производительности.

Кого мы ищем

→ Software Engineer (Telecom Platform)

Требуемый уровень: middle, senior, tech lead.

Чем предстоит заниматься:

• Разработкой платформы для базовых станций LTE/GSM (middleware, high availability, node management, delivery).

• Проектированием архитектуры, работа с C++/Linux.

• Интеграцией с аппаратной и программной частью системы.

• Оптимизацией кода и решение проблем производительности.

• Разработкой API, unit-тестирование, документация.

→ Software Engineer C/C++ (LTE/GSM)

Требуемый уровень: middle, senior, tech lead.

Чем предстоит заниматься:

• Разработкой программного обеспечения для базовых станций LTE.

• Реализацией стека протоколов 3GPP.

• Интеграцией с другими системами, оптимизация кода.

• Решением задач производительности и стабильности системы.

Подробнее о вакансиях и команде читайте на странице SPRINT OFFER. Успейте подать заявку до 9 марта!

Проблемы в работе плагина PVS-Studio для Visual Studio

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

У некоторых пользователей статического анализатора PVS-Studio при использовании плагина для интегрированной среды разработки Microsoft Visual Studio 2022 происходило завершение работы плагина, связанное с внутренней ошибкой. А на экране появлялся страшный список вызовов:

Exception message:

One or more errors occurred.

Exception type:

System.AggregateException

Stack:    at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)

   at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)

   at System.Threading.Tasks.Task.Wait()

   at ProgramVerificationSystems.PVSStudio.PVSStudio.InitializeErrorListWindow(Boolean isFromPackageLoadedEvent) in D:\\JenkinsProjects\\workspace\\proj_PVS_Setup_Docker\\WorkDir\\PVS-Studio\\PVS-Studio\\VsPkg.cs:line 2414

Inner Exception:

Exception message:

Exception from HRESULT: 0x80042007

Exception type:

System.Runtime.InteropServices.COMException



Stack: at Microsoft.VisualStudio.Shell.Interop.IVsShell5.LoadPackageWithContext(Guid& packageGuid, Int32 reason, Guid& context)
....

Возникновение этой ошибки обусловлено тем, что в версии Visual Studio 2022 17.12 был изменён API этой среды разработки для взаимодействия с плагинами. Поэтому в версии PVS-Studio 7.33 мы внесли необходимые изменения в плагин для Visual Studio, и на этой версии с указанной средой разработки анализатор работает корректно.

Следовательно, для решения этой проблемы есть следующие варианты:

• обновить анализатор PVS-Studio до версии 7.33 или выше;

• откатить версию среды разработки Visual Studio 2022 на предыдущую.

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

Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Valerii Filatov. Issues: PVS-Studio plugin for Visual Studio.

«Плюсовое» чтиво: ежемесячная рассылка о разработке на С++

Инженеры YADRO пишут не только статьи, но и письма о «плюсах». Подписчики рассылки раз в месяц получают короткую заметку о том, что важно или интересно разработчикам на С++. Какие письма уже выходили:

— Подборка лучших выступлений с Zero Cost Conf с комментариями Константина Владимирова.
— Презентация новой книги Кирилла Колодяжного о машинном обучении на С++.
— Совет, как избежать проблемы с лямбда-корутинами от ведущего инженера Елены Степановой.

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

Подписаться на рассылку →

Один из пользователей сервиса Highload.fun Joad Nacer прогнал все задачи через GPT O1 и получил интересный результат:

По 2024 году результат расположился на 20 месте с 3,574 очками, как я понимаю код был на C++. В целом нормально, но я, непрофессиональный кодер на C#, разместился на 23 месте, так что я бы оценил кодерство ИИ на уровне студента 1-го курса непрофильной специальности.

В Фреймворк DBGridChart добавлено OLAP-приложение "Экспресс_обработка_таблицы.exe ", позволяющее при разработке программ на C++, Java, Visual Basic, F# и на других языках программирования (имеющих средства выполнения из программы готовых приложений из командной строки с параметрами) автоматическое формирование табличных и ленточных форм, форм с диаграммами и графиками с готовым унифицированным многофункциональным интерфейсом пользователя для корректировки баз данных, OLAP-анализу и прогнозированию данных в табличной и в графической формах.

Таким образом, программист при разработке приложения, даже на языке, отличным от C#, может использовать все средства и возможности Фреймворка DFGridChart путем обращения к приложению "Экспресс_обработка_таблицы.exe " с указанием через параметры значения свойствам, например: текст строки подключения к базе данных, текст команды Select, текст строки подстановки. Порядок формирование таких таблиц определяется интерфейсом (меню, кнопки), разрабатываемого программистом для приложения.

Гиперссылка для скачивания Фреймворка "DBGridChart", OLAP-приложения "Экспресс_обработка.exe" и "Экспресс_обработка_таблицы.exe " с исходными текстами, DLL-библиотеками, документацией и с демонстрационными примерами: https://disk.yandex.ru/d/sI1VhBiSPzDp-A

Пример обращения к приложению "Экспресс_обработка_таблицы.exe " при разработке программы на C++

#include <string>

...

// Символ # должен быть указан перед наименованием свойства!// Внутри строковых констант перед символами \ и " нужно указывать символ \
std::string
program = "C:\\Экспресс_обработка_таблицы\\bin\\Debug\\Экспресс_обработка_таблицы .exe", // Местоположение приложения
p1 = "#ConnString=Provider = Microsoft.Jet.OLEDB.4.0;Data Source="C:\\Демонстрационный пример Экспресс обработка таблицы для C++\\Выпуск изделий.mdb", // Строка подключения к базе данных
p2 = "#DBMS = Access", // Тип СУБД, если не указан (p2 не указано), то определяется по строке подключения
p3 = "#Select = SELECT Подразделения.[Код подразделения]@#,Подразделения.[Наименование подразделения]*, Подразделения.[Численность на 2022], Подразделения.[Численность на 2023], Подразделения.[Численность], Подразделения.[Дата формирования], Подразделения.[Код типа подразделения]*, [Типы подразделений].[Наименование типа подразделения], Подразделения.[Действующее] FROM [Типы подразделений] RIGHT JOIN Подразделения~ ON [Типы подразделений].[Код типа подразделения] = Подразделения.[Код типа подразделения] ORDER BY Подразделения.[Наименование подразделения]", // Запрос с возможностью корректировки таблицы Подразделения. Специальные символы при режиме корректировки после имен полей или псевдонимов: ключевое (@), обязательное (*), не корректируемое (#) поле и после имени корректируемой таблицы указывается символ ~, если таблиц несколько во фразе From.
p4 = "#Podstavit_v_kolonki = ктп #-; SELECT [Наименование типа подразделения], [Код типа подразделения] FROM [Типы подразделений] ORDER BY [Наименование типа подразделения]", //Подстановка кода типа подразделения в колонку с именем ктп по наименованию путем выбора мышкой из списка (сформированного указанной командой Select) наименований типов подразделений. Режимы подстановки: только из списка (-), список открывается в текущей ячейке (#).
p5 = "#Flag_Create_SQL_Select = True", // Разрешить (True)/не разрешить (False) использовать конструктор команд SQL (по умолчанию - True и p5 можно не указывать)
p6 = "#Table_№ = 2367", // Уникальный номер (обычно, случайное число) таблицы или запроса для сохранения макета настройки индивидуально для таблицы
parameters = p1 + p2 + p3 + p4 + p5 + p6, // параметры приложения
command = program + " " + parameters; // командная строка
system(command.c_str()); // выполнение приложения, которое формирует табличную форму с многофункциональным унифицированным интерфейсом Фреймворка DBGridChart

Приветствую, Земляне! Почти 3 месяца миновало с первого релиза NotOnlyClock, моего персонального проекта на платформе Arduino.

За это время вышло 2 обновления, подписчики моего Телеграм-канала всегда узнают обо всем самыми первыми. Обновления получила не только прошивка устройства, но и "железная" часть получила опциональную модификацию: теперь, на устройство можно установить кнопки с подсветкой.

Ниже приведен список ключевых изменений 2-х последних обновлений:

• теперь, можно использовать до 8-ми секундомеров и таймеров одновременно (на 7 больше, чем было доступно ранее);

• добавлен режим для подсчета количества нажатий с 9-ю независимыми счетчиками;

• добавлен Помодоро трекер для отслеживания времени работы и отдыха по методу Помидора.

Подробные описания: обновление 1, обновление 2.

Пишем приложение для поиска объектов на С++ (а не на Python)

Приложения по поиску объектов, написанные на С++, работают ничуть не хуже привычных вариантов на Python. На это есть несколько причин:

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

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

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

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

Если хотите написать такое приложение, изучите материалы инженера YADRO и ML-энтузиаста Кирилла Колодяжного. Он подробно описал, как реализовать программу на С++ с применением библиотек компьютерного зрения.

Подготовительная часть →

Практическая часть →