В нескольких следующих статьях я хотел бы детально рассмотреть настройку окружения VSCode для работы с фреймворком ESP-IDF. Не совсем популярная комбинация ПО обладает как преимуществами, так и недостатками, которые при детальном рассмотрении мы попытаемся исправить, обойти или превратить в достоинства.

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

Поскольку предполагается многопользовательская удаленная разработка, то мы решили вначале отработать выбор и настройку самой среды разработки. После нескольких экспериментов с Eclipse, Visual Studio и QT Creator выбор пал на кроссплатформенный VSCode и плагин от разработчика Espressif IDF для работы с фреймворком ESP-IDF.

В качестве «сердца» контроллера рассмотрим двухъядерный микроконтроллер ESP32, который обладает рядом преимуществ, и которые планируется использовать и раскрыть в проекте, а именно:

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

In concept this is very simple: a nested buffer is just a chunk of binary data stored in a ubyte vector, typically with some convenience methods generated to access a stored buffer. In praxis it adds a lot of complexity.

Что? Зачем?

Всем привет!

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

Если Вы никогда не сталкивались с такой задачей, думаю, Вам будет интересно узнать о ней, посмотреть что это такое.

Если Вы только что-то слышали о выпуклых оболочках, Вы сможете поподробнее разузнать о них.

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

Данная статья является продолжением выступления Евгения Захарова на летней конференции С++ Russia, где была описана разработка пользовательского интерфейса с использованием архитектуры ECS (Entity-Component-System) вместо традиционного наследования и часть устройства UI в World of Tanks Blitz.

В своем докладе Евгений подробно останавливается на том, какие принципы создания фреймворков для UI используются сегодня в мире, а также рассказывает, как можно подружить ECS и UI, и какие плюсы и минусы от этого можно получить в итоге.

В этой статье на небольшом примере UI в World of Tanks Blitz Евгений показывает, в чем большой плюс архитектуры ECS в UI.

Увидело свет очередное обновление небольшой библиотеки для встраивания асинхронного HTTP-сервера в C++ приложения: RESTinio-0.6.12. Хороший повод рассказать о том, как в этой версии с помощью C++ных шаблонов был реализован принцип "не платишь за то, что не используешь".

Заодно в очередной раз можно напомнить о RESTinio, т.к. временами складывается ощущение, что многие C++ники думают, что для встраивания HTTP-сервера в современном C++ есть только Boost.Beast. Что несколько не так, а список существующих и заслуживающих внимания альтернатив приведен в конце статьи.

О чем речь пойдет сегодня?

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

На такое поведение до сих пор никто не жаловался. Но в wish-list-е фича по ограничению принимаемых подключений маячила. Вот дошли руки и до нее.

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

Существует много инструментов для анализа кода: они умеют искать ошибки, «узкие места», плохую архитектуру, предлагать оптимизацию. Но много ли среди них инструментов, которые могут не только найти, но и исправить код сами?

Представьте, что у вас есть большой проект на С или С++ (или даже С#), который разрабатывался много лет и многими людьми. В результате разные части проекта выглядят по-разному – нет единого стиля имен переменных, функций, типов данных. То есть в разных частях проекта использовался разный coding style: где-то имена в верхнем регистре, где-то CamelCase, где-то с префиксами, в других местах – без… Некрасиво, в общем.

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

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

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

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

Сначала о проблеме/задаче:
Начав писать очередной плагин-отладчик для ретро-платформы под IDA Pro (по секрету: это будет SNES), я столкнулся со следующим набором, который требовалось подружить:

1. Ядро эмулятора написано на C++ и компилируется в DLL
2. GUI эмулятора написано на C# и использует DLL-ку ядра для управления эмуляцией
3. IDA Pro, которая использует плагины либо на питоне, либо на C++ в виде DLL (а отладчики только на C++)