Обновился FSME

l -I../diagram -I.. -I/usr/lib/qt-3.1/include -I.ui/ -I.moc/ -o .obj/semantic.o syntax/semantic.cpp syntax/semantic.cpp: In member function `bool Semantic::BlockList::canBreak() const': syntax/semantic.cpp:133: `compose2' undeclared (first use this function) syntax/semantic.cpp:133: (Each undeclared identifier is reported only once for each function it appears in.) make[1]: *** [.obj/semantic.o] Ошибка 1 make[1]: Выход из каталог `/home/tigra/foo/fsme-0.8/ui' make: *** [sub-ui] Ошибка 2

P.S. It works well on gcc-3.3.x

дело в том что этот подход даёт немало выгод при правильном применении и просто незаменим в некоторых случаях (создание сложных сервисов с кучей состояний и сложной схемой переходов между ними). Я не хочу строить из себя сноба и гуру программирования, но лично мне знакомство с этим методом серьёзно облегчило жизнь, главным образом при борьбе со сложностью. Сейчас у меня вызывает недоумение его неизвестность. Советую познакомится с ним поближе:

http://www.softcraft.ru/auto.shtml

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

1) если выполнено условие выхода (заготовка обработана или безнадёжно испорчена :) ) конец цикла, иначе:

2) определение следующей функции-действия (замена инструмента) с помощью функции переходов,

3) вызов функции-действия (обработка инструментом заготовки) из массива-обоймы по адресу или смещению от предыдущей

Выгодность такого подхода заключается в том, что легко добавляются операции-обёртки (всё в одном месте - в теле цикла), например:

1) общение с базой данных легко переводится на транзакции привязанные к определённым состояниям системы - транзакция стартует перед вызовом функции-действия, коммит производится если функция-действие вернулась без ошибок, а откат, соответственно, если была ошибка,

2) тайминг операций организуется также тривиально - оборачиванием вызова функции-действия началом и концом тайминга соответственно.

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

Для программирования с нитями лучше использовать сети Петри, но и автомат может играть тут не последнюю роль.

Автомат можно представить как матекс с логикой, если в генерации текста добавить матекс на функции А. Будет очень интересно.