AHTOXA

Вот тема 1. Вот тема, в которой раскрываются неоднозначности и сложности использования LDREX/STREX. Можно также использовать встроенные в компилятор функции (инстринсики/builtins), вот например для gcc. Полухину просто нравятся головоломки. Я его выступления смотрю как некое шоу:) Но в целом он, по-моему, продвигает в стандарт здравые вещи. Ну и по поводу тенденций развития. Начиная с c++11, и до c++17 включительно мне почти всё нравится. В 20 тоже есть хорошие штуки, но я пока не углублялся. Понятно, что совсем без странных штук не обойтись, но их можно просто не использовать - парадигма "ты платишь только за то, что используешь" более-менее поддерживается.

Идея очень хорошая. Проверка допустимости флагов для данного регистра, подсказки среды разработки. Примерно это же самое ST пытались реализовать на макросах в SPL: #define IS_GPIO_MODE(MODE) (((MODE) == GPIO_Mode_IN)|| ((MODE) == GPIO_Mode_OUT) || \ ((MODE) == GPIO_Mode_AF)|| ((MODE) == GPIO_Mode_AN)) (Ну, понятное дело, что подсказок не было, но хоть какие-то проверки). Но сам бы я сейчас таким заморачиваться не стал. Это подход для писателей библиотек, чтобы пользователю было легко. Для себя проще отладить периферийный драйвер и забыть про этот модуль.

Ссылочку бы. Пока, читая приведённые @Arlleex-ом кусочки, я согласен с мнением, что ненужно:)

Эх, была же хорошая тема. Заглянул узнать, что нового, а тут на тебе - переключились на мерянье пиписьками 🙂

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

По теме "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, например, тоже есть обширная документация, без чтения которой его сложно использовать правильно. И это нормально, на мой взгляд.