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

Кое-где работает. Еще бы свои включения искала).
Вообще давно ищу инструмент, который бы мог проанализировать все #include в проекте на предмет лишних/недостающих/циклических включений.
Может знает кто?

Если они собраны одним компилятором (в одной среде Visual Studio), то почему бы и нет.

Подключения к БД oracle можно выполнить двумя способами.

По SID

C++ (Qt)
QSqlDatabase database = QSqlDatabase::addDatabase( "QOCI", "SchemeName" );
 
database.setDatabaseName( sid );
database.setHostName( host );
database.setPort( port );
database.setUserName( user );
database.setPassword( password );
 

По Service name (текст в методе setDatabaseName не должен содержать пробелов)

C++ (Qt)
QSqlDatabase database = QSqlDatabase::addDatabase( "QOCI", connection_name );
 
database.setDatabaseName(
    QString::fromUtf8( "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=%1)(PORT=%2))(CONNECT_DATA=(SERVICE_NAME=%3)))" )
        .arg( host )
        .arg( port )
        .arg( name );
database.setHostName( QString() );
database.setPort( int()  );
database.setUserName( user );
database.setPassword( password );
 

И вроде как, connection_name не должно быть пустым.

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

Не согласен с таким утверждением.

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

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

Здесь конечный автомат не захардкоден, так как предполагается, что его схема динамически редактируется пользователем.
Схема может быть представлена в виде скрипта, скрипт в виде схемы. Можно реализовать и то и другое, они взаимозаменяемы. Но для того и другого необходим интерпретатор - среда, в которой они должны функционировать.

Если вы используете такой вариант

C++ (Qt)
void ( const QList< int > & values )
{
    ...
    foreach ( const int & value, values )
    {
        const_cast< int & >( value ) = 1;
    }
    ...
}
 

то values не вызывает проверку того, что он shared. Данные будут изменены в обобщенном списке.

Для выполнения detach() необходимо вызвать любой не константный метод values.

И ... "implicit shared" сильно на производительности сказывается, так как не выполняются лишние копирования данных списка.

Реализация foreach в Qt несколько криворукая и имеет описанные ограничения, часто уступает в производительности простому for через итераторы или индексы.
Вот в boost реализация оказалась отличной и без описанных ограничений. Но не тащить же еще и boost 

Такое кастование - это зло, которое нужно срочно искоренить из проекта!
К слову из-за того, что реализация QList implicit shared, таким кодом вы корректируете все взаимосвязанные с данным списком данные.

Если есть необходимость изменения данных в массиве QList, то необходимо использовать либо индексы, либо итераторы, либо C11, либо еще что-то, но никогда кастование!

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

Для сценария необходим парсить, который нужно будет писать. Можно, конечно, взять готовый формат, например svg со всеми его достоинствами и недостатками.
Наглядность сценария для пользователя в виде текста практически нулевая, поэтому нужно графическое представление (которое, скорее всего, все равно сведется к графу).

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

Да, можно.

Структура Vertex, например, плотно пакуется, поэтому можно использовать

C++ (Qt)
struct Vertex
{
   float x;
   float y;
   float z;
}
 
Q_STATIC_ASSERT( sizeof( Vertex ) == 3 * sizeof( floet ) );
 
QVector< Vertex > vertices;
QOpenGLBuffer buffer;
 
...
 
buffer.write( offset, vertices.constData(), 3 * vertices.count() );
 

Все же нужно гарантировать размер, поэтому используем Q_STATIC_ASSERT

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

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


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


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

* Каждое состояние может иметь 1 вход и N выходов, каждый из которых соответствует какому-либо условию выхода из данного состояния.
Например, 1 - закончилось заданное время, 2 - достигли точки назначения, 3 - нажатие кнопки мыши (условие с параметром) , и т.п.

* Соединить можно только выход и вход с одинаковыми выходными/входными параметрами.
* Каждый выход и вход может быть соединен только один раз.
* Пользователь должен задать начальное состояние для объекта.
* Пользователю доступны состояния только из библиотеки состояний.
* Каждое состояние, кроме входящих параметров, может иметь и индивидуальные настройки.
* С разными объектами может быть соотнесен как разные, так один и тот же граф состояний.

Можно попробовать обойтись переходами и без параметров, это будет немного проще.

Для юзера это может выглядеть так:

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

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

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

Диссер действительно интересный. Далее только мои предположения.
Движок, скорее всего, автор не изобретал, а только работал над моделями движения.
Можно, конечно, попытаться списаться с автором и узнать применяемый им инструментарий (иногда получается).
Можно попытаться по косвенным признакам определить команду в которой он работает и их инструментарий.
Однако в собственных приложениях придется писать все самому, скрупулезно изучая теорию.

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