Comments 70
Для курсовой сгодится. От практики бесконечно далеко.

И выкладывать в опенсоурс исходники для СиБилдера6 «с торрентов» это как то за гранью разумного поведения.
Это и есть практика нас, обычных embedderов )). Этот модуль использован во множестве реальных проектов это краеугольный «кирпичик». И для курсовой это отличное задение, его можно использовать как тест на профпригодность, поэтому начинаю именно с него. Поэтому «бесконечно далеко» вызывает лишь искренне недоумение )))
Билдер в данном случае нужен для демонстрации работы модуля на ПК, сам модуль никак не завязан на Билдер, и использовался с другими IDE поэтому ваша критика как будто отчасти имеет почву но она немного мимо.
В дальнейшем я планирую давать примеры в Qt но этот пример было быстрее сделать так.
Кроме того, что код ужасен (я например перечень состояний автоматов с описанием даже не смог найти), для статьи важнее два негативных момента

— куча кода, не относящихся к теме статьи (напомню, она про FSA, а не про битовые сдвиги)

— было бы перед изобретением веслосипеда (я сделяль) неплохо ознакомиться с готовыми наработками. Гуглим C++ finite state machine lib

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

— весь код непосредственно иллюстрирует применение автоматного программирования для проектирования программ, а битовые сдвиги это неотъемлемая часть операционного автомата. И операционный автомат напрямую определяет то, каким будет управляющий автомат. Я верю что вы разбираетесь в автоматах состояний, но субъективно ощущается что знания у вас несколько из другой сферы, попробую объяснить. Судя по комментарию, для вас автомат это только то что непосредственно попадает под формальное определение по запросу C++ finite state machine lib, и до что вы никогда не сталкивались на деление автоматов на операционные и управляющие (может я ошибаюсь, не примите близко к сердцу) и таким образом ваше знание становится камнем преткновения: вы видите то что этот текст не повторяет то что вы привыкли слышать по этому вопросу и это вызывает подсознательную реакцию «что-то не то». Но поймите, автоматы более комплексная сфера знаний чем кажется на первый взгляд. Автоматы могут использоваться в частности для анализа символьных последовательностей и это тоже FSM, но автоматы это также и способ проектирования цифровых логических устройств, и это тоже автоматы, но акцент здесь на другое, и с этой точки зрения автомат это ряд технологических подходов. В статье я рассматриваю автомат именно с этой позиции, т.е. проектирование программного обьекта как цифрового устройства.
Именно так. Но поскольку программа это не цифровое устройство — то в реальности разделение на операционные и управляющие автоматы является искусственным.
С чего я и начал
От практики бесконечно далеко.

Не будем далеко ходить. Вы пишете:
битовые сдвиги это неотъемлемая часть операционного автомата
Но операционный автомат — это логические устройство (алгоритм), а битовый сдвиг — это технический прием формирования выходных данных на аппаратную часть. Соответственно — по теории он относится к управляющему автомату. Путаница как она есть.

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

Но операционный автомат — это логические устройство (алгоритм)

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

Грубо говоря, управляющий автомат в софтвере — это драйвер устройства.
да это верно, вы прекрасно поняли суть. И драйвер много работает именно с битами и байтами, именно на таком уровне как это показано в примере. Микроконтроллер содержит огромное количество готовых встроенных устройств — таймеры цап-ацп, приёмопередатчики, и там такой подход совершенно естественен.
Программирование микроконтроллеров специфическая сфера

Может быть в этом и есть основная проблема? Я честно пытался въехать в статью, но после прочтения, у меня создалось ощущения оторванности теории от показанного примера. Вероятно потому что в пример тяжело въехать из-за специфики. Получается, что абстракция вроде понятна, но за кучей низкоуровневого кода её не видно.
Вначале вы пишите:
Эта статья – попытка взглянуть на программаты глазами прагматика, на примере задачи, взятой из реальной практики программирования микроконтроллеров. Однако она может заинтересовать не только embedderов, поскольку автоматный подход может эффективно использоваться для создания и драйверов и интерактивных приложений в системах основанных на обработке событий, как например Windows.

На мой взгляд, чтобы статья заинтересовала «не только embedderов», нужно как раз показать в качестве примера что-то вроде «интерактивных приложений в системах основанных на обработке событий, как например Windows».
Или же это было сказано «для красного словца», и в реальности, автоматы для прикладных программ неактуальны?
З.Ы. С++ builder 6, goto… Какая же это «новая веха»? В таком виде это даже не миф, а скорее страшилка.
На goto автоматы получаются изящнее. Дело в том, что автомат хорошо описывается графом переходов, а вложенными конструкциями его описывать неудобно.
Идиосинкразия к goto развилась из-за того, что этот оператор резко понижает читаемость кода, однако, в случае конечного автомата картина обратная — здесь безусловный переход практически равноценен вызову процедуры с хвостовой оптимизацией.

Что ж там изящного? goto только для перехода внутри контента. Любой автомат можно реализовать траверсингом ast дерева. Правда ноды должны содержать специальные атрибуты "goto" со значением id записи в контекстном словаре.

Любой автомат можно реализовать траверсингом ast дерева.

Можете рассказать подробнее? На вход автомата подаётся исходная строка. А в Вашем случае нужно отдельное средство для построения ast-дерева?
У меня много материала, постепенно я его изложу, и все заявленные моменты будут раскрыты, это не для красного словца. Сейчас я смотрю на отклики читателей, чтобы выбрать материал для второй части, наберитесь терпения.
Вероятно потому что в пример тяжело въехать из-за специфики. Получается, что абстракция вроде понятна, но за кучей низкоуровневого кода её не видно.
если описание, диаграммы состояний и чертежи перечислить отдельно а код поместить в конце это будет более понятно, я верно уловил?
да уж, я тоже ожидал хотя бы свичей, а не оператор goto, надежность работы которого ЕМНИП многие разработчики ставят под сомнение. Подпишусь под словами Cryvage, что сложно было уловить связь автоматного программирования с примерами кода. Надеюсь, следующие статьи исправят ситуацию.
проведём обзор преимуществ автоматного подхода

По-моему, это должно было быть в начале первой статьи, а не в конце второй. А то на протяжении чтения неизменно сопровождает мысль «ну и зачем всё это?»
К сожалению не получилось всё изложить в одной статье и в то же время хотелось сообщить читателям, что это не всё ), поэтому родилась такая фраза вводящая в заблуждение. Прошу не рассматривать её как указание на то что в этой статье нет описания преимуществ. Обзор подразумевает некую сводку преимуществ. А описание преимуществ уже содержитсяздесь, так как главное преимущество — проектирование программы, данная статья показывает процесс проектирования «вживую», насколько это возможно, как последовательность этапов. А как вы оцените описание самого процесса, вы могли проследить мою авторскую мысль, или где то были какие то непонятности?
Постановку задачи лучше бы явно выделить — сейчас она спрятана в тексте и ищется не так просто.

А почему для реализации был выбран древний C++ Builder 6, а не свежий C++ Builder 10 Starter Edition Free?
Потому что мой основной IDE это IAR а Builder 6 это то, чем я довольно хорошо владею для создания проектов для ПК. Я стал переносить пример на Qt но возникли сомнения в том что если не Qt то кто, и в то же время хотелось выложить статью здесь и сейчас, поэтому решил не заморачиваться. Спасибо вам за идею насчёт Builder 10 Starter Edition Free. Если можно пару слов — вы используете её? И как Starter Edition? Не мешает работе? У меня сейчас выбор между Qt и чем нибудь из Embarcadero, можете вкратце посоветовать его или отсоветовать?
На C++ Builder скорость UI-разработки на порядок выше, зато Qt позволяет разрабатывать UI-приложения под Linux. Мне для небольших ПК-разработок Starter вполне хватает, а вот для рабочих проектов его ограниченность слишком заметна (см. feature-matrix).
Надеюсь, банда четырёх всё же не «изобрели» автоматы, а указали, что описывают реализацию существующего давно изученного формализма?
Имхо, полезно только для машин без динамической аллокации памяти или для глубокой оптимизации, т.к. код на выходе без исходной диаграммы состояний ни читать, ни тем более править не получится.

При наличии ресурсов, значительно более понятное решение можно построить в два шага:
— преобразовать входную строку в структуру данных, описывающую, что и куда рисовать
— передать эту структуру данных в рендер, который занимается отрисовкой
В нормальных FSA-либах это все есть — в начале программы описан автомат таблицей состояний — просто и понятно.
Любая однопоточная программа уже является автоматом. Когда программист пишет код, он мыслит категориями вычислений, чтений, вывода, проверок и переходов.

Дополнительный уровень абстракции (FSM/FSA-либы, ну или просто переменные кодирующие состояния) нужен только в случае асинхронных потоку исполнения входных данных т.е. ввода от пользователя, из сети, из другого потока и абстрагированному, а значит в общем случае не-синхронному, вводу от других компонент в составе того же потока.

Растеризация текстов обычно к таким не относится, поэтому ожидать здесь наличие таблицы состояний странно.
Дело в том что диаграмма состояний строится не для иллюстрации кода а до его создания, поэтому в данном случае она в наличии обязательна.
ответьте пожалуйста на вопрос это важно для меня, если бы у вас перед глазами была диаграмма состояний рис 18 и соответствующий ей код,(и выкладки по сдвигам и прочее — это тоже рисуется до разработки исходника и хранится с ним) вам было бы сложно разобраться в нём и, например, внести дополнения, или чего-то не хватает ещё?
Плюс вопрос, тоже важно ) обратили ли вы внимание что в статье делается акцент не на реализацию программы как автомата, а её проектирование, как автомата. И что на самом деле Out_text_block реализована как обычный алгоритм? Или я недостаточно акцентировал на этом внимание? Потому что в этом соль и есть, это не ещё один велосипед про UML/Boost/Statechart
Да, мне понравилась идея проектирования алгоритмов в виде автомата. НО — такую схему непросто переложить в код без внутреннего состояния — это же противоречит самой идее автоматов.

Человеческий разум устроен так, что ему проще понимать алгоритмы, которым скармливают данные на входе и получают данные на выходе, и результат зависит только от входа, но не от внутреннего состояния. Такие «чистые функции» проще понимать, тестировать и использовать повторно. Также их легче использовать в многопоточном окружении, что актуально для современных многоядерных серверов.

Программа, спроектированная как автомат, будет, конечно же, наиболее эффективной по цпу и памяти, но и наиболее сложной для понимания, так что, имхо, это только техника оптимизации, но не общая техника программирования:
— код, который невозможно понимать и дорабатывать без документации (к тому же, графической документации!) — это слишком дорого для большинства применений
— модификация такого кода может привести к пересмотру хранимого состояния, т.е. придется держать в уме весь код, который этим состоянием пользуется
— состояние перед началом работы нужно инициализировать — этот код тоже «хрупкий» и потребует частых доработок при внесении изменений в логику. А ошибки в нем приведут к сложным багам.

Реализация графа состояний подозрительно напоминает генеренный код — быть может, её и правда можно генерировать по графу состояний? Правда, ни один графический язык пока не взлетел, ну кроме BPML.
такую схему непросто переложить в код без внутреннего состояния

это в точку, но когда я написал
на самом деле Out_text_block реализована как обычный алгоритм

я немного слукавил. На самом деле в этой программе есть явно выделенные состояния. Они заданы метками Type_1 и т.д. Взгляните на этот вопрос математически, программа находится на участке между Type_1 и Type_2 только когда автомат в состоянии Тип 1, и так далее. Это однозначное соответствие. Представьте что вместо метки Type_1, у нас определена функция Type_1 и в программе есть указатель на функцию Current_state (переменная текущего состояния), а вместо операторов goto Type_2 используется конструкция Current_state = Type_2. Я обязательно рассмотрю этот аспект, он изначально заложен в замысел статьи.

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

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

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

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

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

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

Реализация графа состояний подозрительно напоминает генеренный код — быть может, её и правда можно генерировать по графу состояний?

Многолетняя практика. Автоматическая генерация не самоцель. Она требует слишком детальной проработки диаграммы состояний. Диаграмма состояний должна быть ясной и без излишеств, диаграмма состояний не блок-схема, чем понятней диаграмма состояний тем проще и совершенней код. То что моя программа напоминает генеренный код прямое следствие автоматного подхода — иначе просто и не сделать, автоматный подход сам наталкивает на такую реализацию. Но обратите внимание — схемы со сдвигами это тоже немаловажная часть. Повторюсь, такой подход сам наталкивает на такие реализации.

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

Скажите а функция Out_text_block когда у вас есть диаграмма состояний, насколько понятна?

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

Соответствие здесь это метки, они соответствуют названиям состояний.
— преобразовать входную строку в структуру данных, описывающую, что и куда рисовать
— передать эту структуру данных в рендер, который занимается отрисовкой


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

Топикастер тоже проспал эпоху флеша и оператор gotoAndPlay. Вот где были автоматы, потоки, лейауты и всё остальное… Выходим из гибернации. Это очень нужно, но как всегда не всем.

Это любопытно, но флеш анимация серьёзно перекликается с программными автоматами (именно своей кадрированносьтю), спасибо за аналогию.
Если работаете с IAR то должны знать их продукт IAR Visual State
Есть бесплатная триальная версия.
Я бы рекомендовал в ней вам создавать свои автоматы.
Тогда их можно было бы скачать и оценить трудоемкость и эффективность такого подхода.
А также быстро перепроверить насколько ваша реализация отклоняется от проекта.

А рисовать на бумаге диаграммы — это, извините, анахронизм и трата времени.
Я знаком с этим продуктом, если вы знакомы с этим продуктом и взвешенно оцените статью, увидите, здесь речь немного о разных вещах. Там реализация, а здесь сам смысл проектирования. На самом деле с реализацией проблем не возникает, я покажу разные способы. IAR Visual State это дополнение к тому что я говорю, а не антагонист
Понимаете, без формальных схем нарисованных в какой-то стандартной среде, которые можно запустить и проверить возникает стойкое ощущение что вы свои диаграммы нарисовали уже после того как написали программу.
И зачем-то пытаетесь убедить, что применяли автоматное программирование.

я вот что не понимаю.
совсем не понимаю.
каким местом это относится к автоматам?

классически должны были бы быть описания алфавитов входного, внутреннего и выходного алфавитов. Плюс матрицы переходов-выходов, в зависимости от милимура. И собственно вся прелесть автоматного подхода именно в этом: алгоритм меняется простой сменой матрицы. А еще можно приляпать вероятности (и это еще один плюс подхода — нахрен монтекарло), можно приляпать даже интервальные вероятности (с некоторыми ограничениями).
Но вот в статье я таки не увидел ни матриц, ни единого алгоритма.
Читайте Машина Тьюринга
Какую бы программу вы не написали все это можно будет интерпретировать как автомат.
Поэтому если хотите показать настоящее автоматное программирование, то программируйте сразу машину Тьюринга.
Не соглашусь. Математически вы правы, но автомат в данном случае не столько математическая сущность сколько прагматичный подход к практическому созданию алгоритмов. Если честно, меня затруднило бы решить расписанный мной пример в виде машины Тьюринга )
Конечно, любой цифровой компьютер является конечным автоматом по определению.

Весь фокус применения этого способа — в выборе удобного разбиения происходящего процесса на состояния, чтобы это было и удобно описывать и удобно менять детализацию при дроблении состояний.
Согласен полностью.
Но почему-то именно вопрос удобства и не рассматривается.
По сути автор предлагает всегда сопровождать текстовую нотацию графической.
Это удобство?
Это нужно только начинающим программистам, у которых мозг не сформировал областей нужных паттернов мышления.

Присутствие оператора switch в программе на языке C-и тоже не маркер автоматного программирования.
В принципе автоматное программирование это такой спекулятивный термин, что даже Миро Самек от него отошел.
Это нужно только начинающим программистам, у которых мозг не сформировал областей нужных паттернов мышления.

это ваше субъективное мнение,
Присутствие оператора switch в программе на языке C-и тоже не маркер автоматного программирования.

Всё верно, маркер автоматного программирования — набор явно выделенных состояний, плюс текущее состояние задаётся конретной переменной. У меня есть хороший пример.
Я думаю что тема вами пока не раскрыта.
Может следующие статьи что-то раскроют.
Жду.
Автомат автомату рознь. Множество задач роскошно решается конечным автоматом, и применение МТ для них — избыточно.

Какой-то слишком сложный алгоритм у вас. Попробовал реализовать, основная отрисовка занимает 100 строк.
Проверки границ только внутри функций отрисовки символа в буфер строки и буфера строки в видеопамять.
Маску наложения байтов можно вычислять на лету при выводе.
Автомат нужен разве что в разборе escape-последовательностей, как и для любой грамматики. Для остального обычный императивный код будет понятнее.
jsfiddle


Что касается вашего кода в целом. Много глобальных переменных и goto. Поддерживать такой код будет очень сложно. Поэтому программирование на автоматах редко применяется. В основном там, где много однотипных состояний и вариантов перехода между ними — например, в компиляторах.

UFO landed and left these words here

Я так понимаю, в автомате главное это состояние, а состояние в каждой задаче разное. В тех же компиляторах задачи схожие, для них есть библиотеки (ANTLR, Bison), там есть формат описания автоматов. Там и программный код можно дописывать, так что думаю можно применить и для каких-то других задач. Просто никому это не надо, потому что сложно разбираться.

UFO landed and left these words here
фокус в том что любую программу можно рассматривать как автомат. У нее тоже есть состояния, есть переходы межды ними.
Вот только написана она не с использованием автоматного подхода, поэтому возникают неучтённые комбинации параметров и состояний, и всё глючит.

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

Если бы был некий стандарт записи автомата в какой-нибудь xml, позволяющий обмен автоматными алгоритмами, плюс некая «стандартная библиотека», возможно, все бы было иначе;
согласен с вами. Если вы так понимаете суть проблемы вам будет интересно продолжение, потому что то о чем дальше пойдёт речь находится как раз в том тренде о котором вы пишите
Какой-то слишком сложный алгоритм у вас…
Попробовал реализовать
приведите, если не сложно, что у вас получилось.
Маску наложения байтов можно вычислять на лету при выводе.
напишите подробнее пожалуйста, о какой маске идёт речь
Много глобальных переменных и goto. Поддерживать такой код будет очень сложно.
Это не глобальные переменные, это члены класса Display, они общедоступны для функций членов и сокрыты для доступа извне.

нашёл что у вас получилось, запущу это под IAR ом можно будет сравнить с цифрами на руках
о какой маске идёт речь

Я про эти маски: "существуют пересекающиеся байты — байты которые содержат как старые данные из видеопамяти, так и новые данные из строчного буфера".


это члены класса Display

Да, не заметил. Но это мало что меняет. Они глобальны для всего кода отображения и меняются в разных функциях. В сочетании с goto это становится малоподдерживаемым.

Спасибо за весьма корректно выполненную эмуляцию, это то чего мне реально не хватало. если вы не против я возьму её как пример для своей второй части.
PS про маски понятно, за это тоже спасибо. это два подхода которые приятно сравнить, если есть возможность заменить 8ми байтным массивом операцию вычисления маски сдвигом на 7 позиций, лучше использовать массив, потому что взятие индекса одна операция пусть и двухтактная чем 7 сдвигов по одному такту плюс декремент счётчика один такт плюс сравнение и переход плюс ещё пара, итого 28тактов против 2х, выигрыш в производительности 14кратный!!!

goto или jump в мнгогопоточных или многокорных системах нужен в двух случаях — для переключения контекста процесса или ядра и/или для изменения порядка его выполнения. Это способ доступа к адресу элемента. Любоe Deep Learning это веха. Название статьи да — веха. Но пример на веху не тянет..

ваши пояснения туманны, а выводы категоричны. вы в душе поэт ;)?
Очень хорошая и полезная тема в целом. Автору спасибо за труд, НО… большое но…

Я считаю что статью нужно переписать.
Почему?

Вы очень быстро перешли от общего к частному, ко всем этим битовым сдвигам. Честно говоря — от этого голова болит. Вроде как хочешь почитать про FSA, а приходится следить за мыслью, что мы там делаем на битовом уровне.

Это все равно что я буду писать статью про устройство map-reduce системы, но где-то после 1/3 статьи перейду к подробностям оптимизации обмена с диском на некоторых файловых системах с учетом древних косяков API ядра под OpenBSD :) И остальные 2/3 статьи будут об этом, с примерами кода и т.п.

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

Ну и краткое рассмотрение реализации автомата. Какие для этого есть библиотеки, подходы, методы. Хотя наверное это лучше в отдельной статье бы.
одной статьёй не получается, поэтому прошу набраться терпения. Эта статья может рассматриваться как введение, иллюстрация понятия «автоматное проектирование». Сейчас я работаю над второй стаьёй где внимание уделено как философии автоматных программ так и реализации.
А хотелось бы в целом законченную статью про автоматы. С примером разработки автомата. Структурными схемами, и схемой работы каждого автомата.
но у меня же там про разработку ))). Вы просто ставите меня в тупик этой фразой, если можно то более конкретно.
Ну во первых уберите всю эту воду про сдвиговые регистры, экономию тактов и байт памяти. Всё что касается реализации алгоритма уберите из статьи. Я понимаю что это выстраданные долгими ночными часами знания, которыми хочется поделиться. Но в рамках статьи оно все абсолютно неважно и даже вредно.

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

Начните с одного автомата. С проектирования его операционной части, затем управляющей.
Потом покажите как этим автоматом может пользоваться другой автомат. И так далее.

При этом сама реализация в коде не нужна. Достаточно будет диаграммы состояний.

А про реализацию в коде отдельную статью сделайте лучше. Где уже разбираются приемы при помощи которых диаграмма воплощается в код.
Идею уловил. На самом деле трудный пример? Это сквозной и очень хороший пример. Он не такой уж сложный, просто видимо я недостаточно освещаю какие то моменты. Напишите где «и тут всё опять усложняется», я сделаю переходы более плавными и пояснения более развёрнутыми. Во второй части у меня есть разные примеры и в том числе попроще, в том числе реализация этого же примера сделанная моим коллегой, в которой я выделю операционную часть и управляющую и они действительно проще и без сдвиговых регистров. я сравниваю эти две реализации примера: по быстродействию и с точки зрения замысла и здесь сдвиговые регистры ключевой элемент, они определяют почему сделано именно так а не иначе, без них не удастся показать процесс разработки. Может быть имело смысл начать с той реализации, но она появилась как ответ на мою реализацию)))
Про реализацию в коде скорее соглашусь с вами, может её под спойлер лучше?
Будьте любезны, оцените изменения в тексте (начиная с рис 10 и до рис 11), стало понятней?
Only those users with full accounts are able to leave comments. Log in, please.