Третьего дня стала доступна новая версия SObjectizer-а: 5.6.0. Ее главная особенность — это отказ от совместимости с предыдущей стабильной веткой 5.5, поступательно развивавшейся на протяжении четырех с половиной лет.

Основные принципы работы SObjectizer-5 остались прежними. Сообщения, агенты, кооперации и диспетчеры все еще с нами. Но что-то серьезно изменилось, что-то вообще было выброшено. Поэтому просто взять SO-5.6.0 и перекомпилировать свой код уже не получится. Что-то потребуется переписать. Что-то, возможно, придется перепроектировать.

Почему мы несколько лет заботились о совместимости, а потом решились взять и все поломать? И что поломали наиболее основательно?

Об этом я и попробую рассказать в данной статье.

Зачем вообще потребовалось что-то ломать?

Тут как раз все просто.

|1100|110|

Предисловие

Post-mortem отладка на Cortex-M

Предыстория:

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

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

На соплях был прикручен отладочный UART, в который я стал выводить логи. Стало легче, часть проблем решилась. Но потом случился assert и все завертелось.

Если вбить в яндекс 'aes 128 ecb mode', найдутся хорошие статьи ребят на "хабре": раз и два — толковые и одновременно слишком подробные.

Рассказ об алгоритме в картинках находится здесь (который также можно найти по ссылкам в одной из статей ребят выше).

Кратко об алгоритме: 1) создаем объект с 16-байтным state и массивом 16-байтных ключей; 2) пишем примитивы для объекта (они же трансформации); 3) запускаем n раз (где n — кол-во раундов). Все трансформации делаем симметричными — для зашифровки и расшифровки одновременно. Расшифровка в терминах алгоритма — это зашифровка наоборот.

Структура:

using byte_t = unsigned char;
struct aes128 {
  aes128(const std::string& text, const std::string& cipher, bool decrypt = false)
    : state({begin(text), end(text)}), keys({{begin(cipher), end(cipher)}}), decrypt(decrypt) {}
  aes128() = default;
  aes128(const aes128&) = default;

  std::vector<byte_t> state;
  std::vector<std::vector<byte_t>> keys;
  bool decrypt;
}

Пару лет назад мы опубликовали RESTinio — свой небольшой OpenSource C++фреймворк для встраивания HTTP-сервера в C++ приложения. Мегапопулярным за это время RESTinio не стал, но и не потерялся. Кто-то выбирает его за "родную" поддержку Windows, кто-то за какие-то отдельные фичи (вроде поддержки sendfile), кто-то за соотношение возможностей, простоты использования и настраиваемости. Но, думаю, изначально многих RESTinio привлекает вот этим лаконичным "Hello, World"-ом:

#include <restinio/all.hpp>
int main()
{
    restinio::run(
        restinio::on_this_thread()
        .port(8080)
        .address("localhost")
        .request_handler([](auto req) {
            return req->create_response().set_body("Hello, World!").done();
        }));
    return 0;
}

Это, действительно, все, что нужно чтобы запустить HTTP-сервер внутри C++ приложения.

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

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

Ситуация, когда код на языке C++ синтаксически валиден, однако его поведение не определено в Стандарте, в русскоязычной литературе часто называют просто неопределённым поведением. В самом же Стандарте для таких ситуаций существуют целых 3 термина: undefined behavior, unspecified behavior и implementation-defined behavior. В этой коротенькой заметке мы будем разбираться, чем они отличаются.

Сравнительное тестирование многопоточных кэшей реализованных на C/C++ и описание как устроен LRU/MRU кэш серии O(n)Cache**RU