Предложение добавить поддержку statemachine для C ++ - подобного языка

Question

В последнее время, как часть моей повседневной работы, я изучал IBM Rhapsody и использовал ее для генерации кода на C ++ из UML.

Вчера меня поразило, что было бы здорово подумать о добавлении поддержки конечного автомата в мой компилятор C ++, поэтому я написал здесь несколько замечаний: http://ellcc.org/wiki/index.php/State_machines_and_Active_Classes

Мои мотивы для этого:

1. Кажется, это крутая идея.
2. Компилятор мог бы сделать намного лучшую семантическую проверку (с лучшей проверкой ошибок), чем текущий компилятор Rhapsody / normal C ++.
3. Существует множество возможностей оптимизации, когда сам компилятор понимает структуру конечного автомата.

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

Что вы думаете о предложении? Кажется ли это читабельным? Это кажется стоящим? <Ч /> Edit:

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

Я действительно искал идеи, критику и т. Д. О дизайне расширения конечного автомата для языка, подобного C ++, а не о том, будет ли это изменение подходящим для добавления в стандарт C ++. Думайте об этом как о доменном расширении, где мой мой домен - приложения управления в реальном времени.

Я начал реализацию расширения в моем компиляторе, как описано здесь: http://ellcc.org/wiki/index.php/State%5Fmachines%5Fand%5FActive%5FClasses

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

Время покажет, имеет ли вся концепция какое-либо значение. ; -)

Answer 1

За некоторыми исключениями, C ++ традиционно расширяется за счет использования библиотек классов, а не новых ключевых слов. Конечные автоматы могут быть легко реализованы с использованием таких библиотек, поэтому я не думаю, что у вашего предложения есть много шансов.

Одна проблема, которую я вижу в вашем предложении, - это использование «goto» для перехода в другой штат. Что произойдет, если я захочу использовать goto в своем собственном коде при переходе между состояниями?

Answer 2

Вы должны взглянуть на то, как другой умный разработчик добавил поддержку конечного автомата к языку C-like: Справочник по языку UnrealScript . См. Раздел «Штаты».

UnrealScript поддерживает состояния на уровень языка. В UnrealScript каждый Актер в мире всегда в одном и только одно государство. Его состояние отражает действие, которое оно хочет выполнить. За Например, движущиеся кисти имеют несколько такие состояния, как "StandOpenTimed" и "BumpOpenTimed". Пешки имеют несколько такие состояния, как «Умирающий», «Атакующий», и "Блуждающий". В UnrealScript вы может написать функции и код, который существуют в определенном состоянии. Эти функции вызываются только когда актер в таком состоянии

Answer 3

Отличная работа по разработке того, что вы сделали. Что-то вроде того, что вы сделали, возможно, возможно, но я сомневаюсь, что это когда-нибудь попадет в C ++. Большинство изменений, которые вносятся в сам язык, включены только для того, чтобы люди могли писать более полезные и мощные библиотеки.

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

http://www.boost.org/doc/libs/1_34_1/libs/statechart/doc/index.html

Или вы можете разработать свое собственное расширение, как вы предлагаете, и оно, по крайней мере, будет полезно для вас. Microsoft реализует некоторые ключевые слова расширения, поэтому нет причины, по которой вы не могли бы создать собственную расширенную версию C ++.

Поддерживайте приход новых идей.

Answer 4

Прочитайте ваше предложение, оставьте следующие комментарии:

1. На самом деле нет ключевого слова для объявления и определения фактического конечного автомата! Предполагаете ли вы один глобальный конечный автомат (и, следовательно, один глобальный состояние)? Как это относится к __active__?

2. Самая близкая сопоставимая конструкция в C ++ на самом деле - enum. Почему бы не продлить его?

3. Кажется, есть некоторая связь между определенными событиями и состояниями, но я не вижу, как это реализовано.

4. Зачем нужны потоки и таймеры? Некоторые варианты использования конечных автоматов могут извлечь из них пользу, но хорошее предложение должно держать их отдельно. Самое главное, это должно позволить использовать стандартные потоки C ++ 0x.

Лично я бы расширил синтаксис enum:

enum Foo {
  red, blue, green; /* Standard C++ so far - defines states. State list ends with a ; not a , */ 
  Foo() { *this = red; } // Reuse ctor syntax, instead of __initial__
  ~Foo() { } // reuse dtor syntax, instead of __onexit__

  void Bar() {/**/} // Defines an event, no return value. Doesn't need keyword __event__
};

Естественно, теперь вы можете объявить свои события в заголовке и определить их в файле .cpp. Мне даже не нужно предлагать синтаксис здесь, любой программист C ++ может догадаться об этом на данный момент. Добавьте немного синтаксиса наследования для комбинированных состояний:

enum DrawingObject : public Shape, public Color { /** } // allows (red && circle)

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

Answer 5

Ваше решение не выглядит так, как будто оно имеет какие-либо преимущества перед решением на основе шаблонов или макросов препроцессора.

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

Однако, чтобы обеспечить лучшую оптимизацию и семантическую проверку, вы также должны заменить «goto» новым ключевым словом (например, __change__ newState) и запретить goto для изменений состояния! Разрешить goto для локальных прыжков как обычно.

Затем компилятор может извлечь список возможных переходов.

Answer 6

Это интересная идея, но я думаю, что вам на самом деле повезет больше, если вы создадите свой собственный предметно-ориентированный язык для конечных автоматов, чем официально расширяете C ++. C ++ разработан как язык программирования очень общего назначения. Я думаю, что Boost доказал, что C ++ достаточно гибок, чтобы большинство функций можно было реализовать с использованием библиотек. Он также развивается очень медленно, поскольку в стандартном C ++ до сих пор даже нет встроенной поддержки многопоточности (планируется в 0x). Так что вряд ли комитет рассмотрит это дополнение в течение некоторого времени.