Привет! Мы - команда симулятора Союз ТМА, программы, имитирующей орбитальный полёт космического аппарата Союз и Международной Космической Станции, сближение и стыковку КА с МКС, а так же расстыковку и спуск. Всё это имитируется как в автоматическом (т.е. под управлением моделями бортовой аппаратуры Системы Управления Движением), так и в ручном режимах полёта, которые по своему алгоритмическому и логическому составу идентичны тем. что использовались на борту КА Союз ТМА.

Нами разработано программное обеспечение под названием "Моделирование и Управление" в среде C++ Builder 6. Почему именно в ней, а не в VS - это наш первый проект и ранее никто из нас не имел опыта в программировании, а тем более в тренажёростроении, поэтому для "пробы пера" была выбрана наиболее простая среда, но при этом код разрабатывается так, что бы его можно было максимально быстро интегрировать в другую среду (Qt, VS).

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

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

В этот список входят несколько групп параметров:

Система логирования ALog первоначально разрабатывалась для использования в серверных приложениях. Первая реализация ALog была выполнена в 2013 году, на тот момент я и подумать не мог, что спустя семь лет буду писать про нее статью на Хабр. Но, видимо, на все воля случая… Сейчас уже и не вспомню, что именно искал на просторах интернета, когда мне на глаза попалась статья Сравнение библиотек логирования. Я решил бегло просмотреть её в ознакомительных целях. По мере знакомства с материалом в голове возникла мысль: "А где же в этом 'табеле о рангах' находится мой логгер?".

Бытует мнение, что C# не место в вычислительных задачах, и мнение это вполне обоснованное: JIT-компилятор вынужден компилировать и оптимизировать код на лету в процессе выполнения программы с минимальными задержками, у него попросту нет возможности потратить больше вычислительных ресурсов, чтобы сгенерить более эффективный код, в отличие от компилятора C++, которые может потратить на это дело минуты и даже часы.

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

И вот стало мне интересно: а можно ли в 2020 году, используя .NET 5.0, написать код, который бы не сильно уступал по производительности C++? Оказалось, что можно.

Все топовые языки программирования уже давно доказали свои позиции и "определились" с нишами своего использования.

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

Измерять можно довольно много параметров и для разных целей.

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

В данной статье мы рассмотрим ускорение программы с использованием JIT-компиляции для языков Python и PHP.

В качестве задачи для расчёта возьмём функцию проверки - является ли число Простыми или нет - "is prime". Возьмём базовый алгоритм проверки на то, что число Простое:

В статье приводится описание того:

- Как создать посетитель не привязанный к предметной области.

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

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

Регулярные выражения (Regular expressions или, вкратце, regex — регулярки) — это пока что непопулярная и недооцененная тема в современном C++. Но в то же время разумное использование регулярных выражений может избавить вас от написания множества строчек кода. Если у вас уже есть какой-никакой опыт работы в индустрии, но вы не умеете использовать регулярные выражения — вы разбазариваете 20-30% своей продуктивности. Я настоятельно рекомендую вам освоить регулярные выражение, так как это единовременная инвестиция в себя (по известному принципу “learn once, write anywhere”).

• std::stacktrace,
• z и uz,
• 61 с половиной багфикс в ядре языка,
• string::contains,
• Executors & Networking,
• и прочие новости.

• В отладчике появились возможности исследовать дампы памяти и запускать конфигурацию с привилегиями администратора. А еще теперь можно перемещать точку исполнения по коду в любом направлении прямо во время сеанса отладки.
  
• Для модульного тестирования мы добавили поддержку CTest — инструмента запуска тестов, идущего в комплекте с проектной моделью CMake.
  
• Для проектов на Qt добавлены шаблоны для создания новых Qt-проектов и новых классов UI, функция автодополнения адаптирована для работы с сигналами и слотами, а автоимпорт следует принятому в Qt стилю.
  
• Существенно расширилось множество проектов, использующих Makefile, которые можно успешно открывать в CLion. А для проектов CMake появилась возможность отключать временно неиспользуемые профили CMake.
  
• Для разработчиков встроенных систем мы включили начальную поддержку стандартов MISRA C 2012 и MISRA C ++ 2008.
  
• А также множество других улучшений для конфигураций запуска и отладки, в поддержке систем контроля версий и для режима удаленной разработки. Разнообразные приятные улучшения в UI. И… долгожданное превью нового сервиса для совместной разработки и парного программирования.
  

SObjectizer — это небольшой фреймворк для C++, который дает возможность разработчику использовать такие подходы, как Actor Model, Communicating Sequential Processes и Publish/Subscribe.

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

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

Сегодня мы еще раз поговорим об этом. На примере уже другой задачи. Да и реализация будет отличаться, поскольку за прошедшее время SObjectizer успел обновиться сперва до версии 5.6, а затем и 5.7. И в этих версиях много отличий от версии 5.5, про которую в основном и рассказывалось в прошлом. В том числе и в механизме диспетчеров.

О решаемой задаче в двух словах

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

Сообщения msg_status могут идти большим потоком. Например, на одно msg_result может приходиться до 1000 msg_status. И нам бы хотелось, чтобы когда в очереди уже стоит 900 сообщений msg_status, новое сообщение msg_result вставало не в конец очереди, а в самое ее начало. Чтобы msg_result не ждало, пока разгребутся 900 старых msg_status.

Небольшие, но важные функции

Начиная с C++20 в несколько стандартных контейнеров, включая std::map, std::set и std::string, были добавлены некоторые очень полезные функции для поиска. Необходимость в них существовала уже в течении достаточно долгого времени, и мне приятно видеть, что комитет наконец признал их важность. Надеюсь, это только начало серии замечательных дополнений.

Бенчмарк Phoronix в настоящее время использует build2 0.12.0, у нас 0.13.0 (текущий релиз), здесь сборка выполняется примерно на 10% медленнее.

В нескольких следующих статьях я хотел бы детально рассмотреть настройку окружения 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.