LINUX.ORG.RU

Как бы покрасивее заменить отсутствующие генераторы?

 , ,


0

3

https://github.com/speedcontrols/ac_sc_grinder/blob/master/src/calibrator.h

Как можно покрасивее записать бизнес-логику? В процессе калибровки надо проделать линейную последовательность действий. Местами иногда бывают циклы, но без фанатизма. Снаружи это все дергается через метод ".tick()", а дальше «крутись как хочешь».

Не нравится мне как выглядит код. Ни когда это был единый switch, ни после разбивки на мелкие функции. Суть простого алгоритма тонет в особенностях реализации. Что можно придумать, чтобы улучшить читаемость?

PS. Тащить ради этого RTOS как-то не хочется.

★★★★★

ничтожный неосилятор, погугли про либы конечных автоматов. хинт: в бусте есть

anonymous
()

Суть простого алгоритма тонет в особенностях реализации

Ну не знаю, на мой неискушённый взгляд всё вполне понятно. Можно конечно как советует анонимус запилить абстрактную стейт-машину и формальное описание алгоритма к ней, но зачем? Тебе шашечки, или ехать?

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

на мой неискушённый взгляд всё вполне понятно

Все так думают, пока не приходит время изменить что-то нетривиальное.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

изменить что-то нетривиальное

Ну у ТСа и так уже стейт-машина, только сделанная на коленке. Добавление абстракции ничего существенно в плане «сделать нетривиальное» не улучшит.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Я в курсе про FSM, хотелось бы примеров, чтобы оценить наглядность.

В жабскрипте/питоне линейная логика с локальными циклами очень хорошо описывается через async/await. Хотелось бы что-то подобное по простоте чтения.

Vit ★★★★★
() автор топика

Одну функцию c учётом малого объёма кода принимающую флаги, внутри

enum
{
 FLAG1,
 FLAG2,
 FLAG3,
 UNDEFINED_FLAG
};
int handler(int FLAG)
{
   if(FLAG == FLAG1)
   {
     ...
     return result;
   };
   if(FLAG == FLAG2)
   {
     ...
     return result;
   };
   ...
   return UNDEFINED_FLAG;
}

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

У нас видимо очень отличаются представления, что такое хорошо читаемый код :). Сорри, но такое мне не подойдет. Можно посмотреть в предыдущем коммите, большой switch уже был.

Vit ★★★★★
() автор топика
Ответ на: комментарий от Vit

psomise/future есть и в С++ async wait уже в тестировании, кому надо тот может пользоваться, в бусте полно тоже всякого, вообще вбросы у вас толстые и сам вы на аве тот еще тролль

anonymous
()
Ответ на: комментарий от no-such-file

Если я правильно понимаю, ТС хочет линейный код и сохранение состояния в блоке, а не размазанный по функциям КА, сохраняющий состояние в полях объекта.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Да, это был бы идеальный вариант.

Переменные в свойствах объекта наверное не страшно. Но switch уже как-то стремно выглядит.

Vit ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

а не размазанный по функциям КА, сохраняющий состояние в полях объекта

Ну КА можно вытащить в отдельный класс и наделать объектов состояний с методом run, выкинув т.о. switch... Станет ещё размазаннее.

no-such-file ★★★★★
()
Ответ на: комментарий от hateyoufeel

Они уже есть и соберутся под эмбеды во что-то вменяемое? Можно примеры посмотреть?

Vit ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

Надо под stm32, желательно чтобы просто добавить хедер и юзать async/await (ну или обертку типа JS-ного «co» и yield).

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

Vit ★★★★★
() автор топика
Ответ на: комментарий от Vit

Ну наверное, для меня читабельность это интерфейс то есть что принимает и возвращает функция,потому что читается в первую очередь не внутреннее устройство функции,а использующий её код,и то насколько продуман интерфейс взаимодействия с нет и будет качеством её читабельности, внутренне её устройство должно отражать и соответствовать тому что она делает даже в ущерб читабельности реализации этой функции, а так... код плотнее и прямолинейнее. гы ))

Deleted
()

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

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

anonymous
()
Ответ на: комментарий от Vit

не хотите switch - ну сделайте указатель на функцию и дёргайте её каждый тик, и вместо смены состояния - смена функции. Шило на мыло, конечно.

Слышал, в gcc есть расширение, чтобы брать адрес метки и делать потом goto по нему; не знаю, доступно ли оно вам, но по идее можно накостылять что-то вроде генераторов так

dumdum
()
Ответ на: комментарий от dumdum

Дык не хочется шило на мыло, хочется красиво.

Нашел protothreads https://github.com/zserge/pt, который точно взлетает на stm32. Забавная штука, но еще не решил, стоит ли возиться при моем нежелании погружаться в сишечку.

Пока вытащил логически осмысленные блоки во вложенные FSM. Вроде уже не так тошнотно, хоть и далеко от идеала.

Vit ★★★★★
() автор топика
Ответ на: комментарий от Deleted

для котролёров только хардкор только асм!

anonymous
()
Ответ на: комментарий от Vit

моя же идея в том, чтобы функцию например начать с if(addr != NULL) goto *addr;, а затем выходить из неё посредством

addr = &&label; return x;
label:
и когда это вызовется, следующий вызов tick() продолжит с этого же места. В теории. Кажется, в этой либе тоже так делают.

dumdum
()
Ответ на: комментарий от dumdum

поздравляю вы изобрели стеклес корутины, которые есть в бусте,обмазываются макросами и скоро вместо макросов будут в С++20

anonymous
()
Ответ на: комментарий от anonymous

вечно какой-то козёл мои супер идеи крадёт и отправляет на машине времени в прошлое

dumdum
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.