AHTOXA

Это ещё ничего. Хуже, когда подхватываемый проект написан в виде классической си-лапши с тоннами копипасты и глобальных переменных. Вот это да, вот это смешно:)

По теме "FSM на плюсах" меня в своё время очень впечатлил доклад одного товарища на cppcon. Там под капотом std::variant, для итерации по состояниям используется std::visit(), и проверка полноты таблицы переходов осуществляется на этапе компиляции. Клёво получается. И очень быстро. Я даже реализовал парочку таких машин для интереса. Но в реальных проектах не применил - не дошли руки. ЗЫ. Вот презентация от этого доклада. effective_replacement_of_dynamic_polymorphism_with_stdvariant__mateusz_pusz__cppcon_2018.pdf

У меня какой-то Titan -2100 (LED) (вот примерно такой). Антенна направленная (не такая как по ссылке). Без усилителя телефон пишет "нет сети". С усилителем нормально, связь есть, интернет давал до 10МБит вниз /3Мбит вверх. Помню, долго разбирался со всеми этими диапазонами. Покупал на озоне года 3 назад. С тех пор всё нормально, но OLED-экранчик совсем выцвел, ничего на нём не видно.

Можно просто добавить в базовый класс функцию getU32(), и передавать по протоколу этот u32.

Можно, но это будет просто struct с функциями. В целом нам, эмбеддерам, проще - проверил на целевом компиляторе, и порядок. При смене платформы, возможно придётся повторить проверки, но это небольшая потеря на фоне остальных дел, которые надо сделать при смене платформы:) Так что базовый класс с uint32_t и функциями доступа - вполне надёжное решение. Да даже и с битовыми полями всё работает, но я их всё-таки стараюсь избегать.

Я отвечал на вот это сообщение:

На самом деле тут проблема не только в наследовании, но ещё и в битовых полях. А вот они не переносимы по определению. Чушь какая. Очень даже поддерживает.

Здесь совершенно не обязательно нужен умный указатель, подойдёт и обычный. Суть в том, что мы в интерфейсном классе объявляем указатель на класс-реализацию: // Foo.h class FooImpl; // forward-объявление класса реализации class Foo { public: Foo(); void somePublicFunc1(); void somePublicFunc2(); private: FooImpl* impl; } , а весь класс реализации целиком помещаем в *.cpp-файл: // Foo.cpp #include "Foo.h" struct FooImpl { void func1() // это у нас получается как бы приватная функция класса Foo, но её не видно в Foo.h { } int field1; // а это как бы приватные мемберы. int field2; }; void Foo::somePublicFunc1() { impl->field1++; // работаем с "приватным" членом impl->func1(); // вызываем "приватную" функцию } // конструктор Foo::Foo() { impl = new FooImpl; } Добавлю, что можно даже избежать использования динамической памяти, объявив в Foo массив достаточного размера, и расположив FooImpl поверх этого массива при помощи placement new.

Здесь можно вспомнить про идиому pimpl, которая, кроме припрятывания приватных дел в cpp-файл, теоретически позволяет уменьшить число перекомпиляций (можно много что менять в реализации без изменений в *.h-файле.

Нет, это их нестандартное языковое расширение. Чтобы с delphi-кодом взаимодействовать. Я в последнее время не люблю неявных вещей. Пишешь obj.length=0, вроде бы простое присвоение. А оказывается, что там под капотом куча побочных действий происходит. Лучше уж obj.setLength(0). Не особо длиннее, но зато явно видно вызов функции.

А почему это должно стать очевидным? Для std::shared_ptr, например, тоже есть обширная документация, без чтения которой его сложно использовать правильно. И это нормально, на мой взгляд.

Насколько я понял, это заголовочный файл от System.DynamicArray (из RAD Studio, который давным-давно был C++ Builder). Это очень навороченный тип, с подсчётом ссылок, итераторами, свойствами (нестандартное расширение языка, емнимс), и прочим подобным. Понятное дело, что выглядит мощно 🙂 Кучу конструкторов с разным числом параметров можно выкинуть, оставив только ветку для c++11. И так далее.

Можно crc засунуть в Header, раз уж он у всех пакетов есть. Насколько я понимаю, и N будет там же, в Header. А в конце будет byte[maxLen]. Ну а почему бы и не написать, если небольшой? 🙂

Это по-каковски? Если с английского, то яндыкс-переводчик пишет agile[ˈæʤaɪl]прил

О, оказывается всё ещё сложнее: отображение зависит от темы. В моей теме (Electronix Neoclassic (по умолчанию)) - сейчас не видно ни уровня, ни звания. А если я включаю тему "Electronix Classic 4.5.2", то видно уровень (над аватаркой), причём мой уровень по-прежнему "фанат дивана" 🙂 А отображение звания, как я понимаю, сейчас уже отключили.