Статическое константное дерево на шаблонах C++

Ого, а я думал, что 128 только у китайских клонов cs32f103c8t6. Круто, спасибо, буду знать и меньше экономить:)

Статическое константное дерево на шаблонах C++

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

Статическое константное дерево на шаблонах C++

В этом плане не могу не согласиться, что такая опасность есть. Жаль, мой уровень квалификации не позволяет нормально оценить влияние раздутого кода на выполнение программы. Наверно, если когда-то вздумается тащить всё в продакшн, следует провести качественные эксперименты.

Статическое константное дерево на шаблонах C++

Не совсем понял: у нас есть известный набор ключей, а в runtime мы от устройства получаем строку, ее как-то нужно «на лету» преобразовать?

Статическое константное дерево на шаблонах C++

Вы правы, с числовыми ключами это бессмысленно, но глобальная идея в использовании префиксного дерева, а там сравнение ключей сильно отличается, Patricia, на которое я нацелился, подразумевает сравнение одного лишь бита в каждом узле.
Также к своему стыду признаюсь, что так и не понял, можно ли статический массив разместить во Flash, а доступ к нему получать в runtime? Или придется все равно городить список типов?

template<int... Numbers>

Статическое константное дерево на шаблонах C++

А побочной целью было еще и перенести данные во Flash (раз уж они все равно неизменные).

Статическое константное дерево на шаблонах C++

Бегло посмотрел справку на std::lower_bound/upper_bound, они принимают конкретные runtime-параметры, тогда вопрос: в какой памяти окажется этот массив? Да, он статический и constexpr, то есть проинициализирован целиком в compile-time, однако какую память будет в итоге занимать?

Статическое константное дерево на шаблонах C++

Не знал про такой проект, пролистал описание, выглядит очень интересно, спасибо! Более чем возможно, что получится его применить в своем проекте, а не изобретать велосипед, как обычно бывает :(

Статическое константное дерево на шаблонах C++

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

Статическое константное дерево на шаблонах C++

Да, по сути, это switch-case, но именно бинарный, то есть поиск все же за O(logn).
Динамическое добавление узлов здесь никак, к сожалению (это уже реальные объекты, а их у меня нет вовсе).

Статическое константное дерево на шаблонах C++

Кстати интересная мысль! Насколько я помню, несовпадение хешей означает 100% отличия ключей, но совпадение (что очевидно) не гарантирует их равенство. В случае с МК строковых констант будет очень и очень немного, что позволяет надеяться на отсутствие коллизий (+ их на этапе компиляции можно обнаружить) и тогда действительно строковые ключи с большой вероятностью можно превратить в числовые.

Статическое константное дерево на шаблонах C++

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

Статическое константное дерево на шаблонах C++

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

CoroOS: концепт операционной системы для микроконтролеров на корутинах С++20

Наверно, основоположником (по крайней мере в рунете) можно считать упомянутого выше Чижова, ВОТ его проект на github.

Находим аномалии в российской статистике COVID-19

Последня цифра номера может быть контрольным числом

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

Право на ремонт набирает обороты: теперь ремонтировать можно автомобили, ТВ-приставки, роутеры и не только

И это увеличит кол-во мусора.

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

Настройка VSCode для программирования stm32 в Linux и не только в Linux

Мне кажется, странно предъявлять претензий к PlatformIO по поводу разрастания проекта и тут же использовать HAL, который тоже тащит кучу всего, причем прямиком в прошивку.

Оптимизированный доступ к GPIO. Или GPIO как constexpr класс. С++

Конечно, буду более чем рад. Можно зайти в любую из моих статей, везде внизу есть ссылка на github (здесь не буду оставлять, думаю, это не очень красиво будет, как реклама).

Оптимизированный доступ к GPIO. Или GPIO как constexpr класс. С++

My bad, не сразу понял, что Goron_Dekar имел ввиду. Перечитал и осознал, что идея именно для списка пинов применять настройки. Мой пример делает это для списка портов, но и для пинов есть соответствующий функционал, который заключается в получении для списка пинов списка портов (причем уникального).
Получаю список портов так:

using UsedPorts = typename Unique<TypeList<typename _Pins::Port...>>::type;

Ну, собственно, этот список портов уже применим для предложенного выше кода.

Оптимизированный доступ к GPIO. Или GPIO как constexpr класс. С++

Это есть у Чижова, список типов, инстанцированный нужным набором портов. При разработке форка его mcucpp я тоже такое добавил, чтобы при настройке PinList-а одной строкой все используемые порты настроить (+ добавил уникальность). Вот так примерно выглядит:

template<typename... _Ports>
class PortList<TemplateUtils::TypeList<_Ports...> >
{
public:
	static void Enable()
	{
		(_Ports::Enable(), ...);
	}

	static void Disable()
	{
		(_Ports::Disable(), ...);
	}
};