Что значит "несовместимы"? Если имитация имеет физический смысл, то вектор результирующей силы как раз будет равен сумме всех действующих сил.

Наследование от QThread и вызов в конструкторе moveToThread(this) дает, конечно, необходимый результат, и при быстром решении конкретной задачи может быть использован.
Я предложил решение, рассматривая задачу в общем виде (я же не знаю заранее, как будет использован Worker).
В случае же наследования и использования moveToThread(this) существуют ограничения, о которых необходимо помнить

Нельзя указывать родителя, иначе moveToThread не сработает.
Если объект без родителя создан в куче (через new), а не на стеке, то необходимо использовать соединение с deleteLater, что иногда является настоящим геморроем.
Если объект создан на стеке, то его принудительное удаление может быть вызвано в момент его работы в другом потоке, что приведет к crash.

Все эти нюансы могут быть неочевидны программистам с малым опытом работы с Qt, его QObject и QThread.

Именно, про ошибки такого рода я и писал

C++ (Qt)
 
Worker::Worker(QObject *parent) : QObject(parent) {
	connect( &_thread, &QThread::started, this, &Worker::process );
	connect( MainWindow::ui().startPushButton, &QPushButton::clicked, this, &Worker::start );
	connect( MainWindow::ui().signalPushButton, &QPushButton::clicked, this, &Worker::slot );
}
 
 

Здесь соединяются сигналы и слоты способом Qt::DirectConnection. Вызов сигнала и далее вызов слота всегда будет в потоке вызвавшем &QPushButton::clicked, сколько бы мы не делали moveToThread для Worker. Таким образом запуск отдельного потока ничего не даст.

Наследование от QThread не расширяет функциональность, а всего лишь вынужденная необходимость, как и наследование от QObject.
При этом QThread сам является QObject и функционирует в потоке, в котором был создан. Метод run единственный метод QThread, который вызывается в отдельном потоке.

Да, давно такого чуда не видел  . Вообще метод moveToThread считаю вредным, о позволяет писать небрежный код и приводит к ошибкам, которые долго ищутся - с виду то все ок.
Например, сначала произвели подключение сигналов и слотов, получили DirectConnection, а затем сделали moveToThread и получили кучу проблем, так как вместо DirectConnection должно было быть QueredConnection. Это всего лишь простой пример, не говорю уже о проблемах с удалениями таких объектов и т.п.

Предлагаю сделать так

C++ (Qt)
 
class Worker
    : public QObject
{
    Q_OBJECT
 
    // ...
 
    Q_SLOT void processSlot ();
};
 
 
class WorkThread
    : public QThread
{
    Q_OBJECT
 
private:
    Worker m_worker;
 
public:
    WorkThread ( QObject * const parent = 0 );
 
protected:
    virtual void run () final;
 
public:
    Q_SIGNAL void processSlot ();
};
 
 

Реализация

C++ (Qt)
 
void Worker::processSlot ()
{
    // my process realization
};
 
void WorkThread::run ()
{
    Worker worker;
    connect( this, &WorkThread::processSlot, &worker, &Worker::processSlot );
    exec();
}
 
 

использование в коде

C++ (Qt)
 
void foo ()
{
    // ...
    WorkThread thread;
    connect( &invoker, &processInvoked, thread, &processSlot );
    thread.start();
    // ...
};
 
 

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

Вы уверены, что такое использование memset безопасно? Надеюсь не забыли по необходимость явного удаления IModelItem через delete в таком массиве.
Почему бы не воспользоваться стандартными методами std::vector?

Сразу напрашивается вопрос - strInfoList.at(0) существует? Т.е. размер списка strInfoList больше нуля.
Чтобы не проверять можно использовать strInfoList.value(0).

Второй возможный вариант - memcpy нигде не используется?

Операционка ни при чем.

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

Каким образом предполагалось обращение EditorToolBar к вышестоящему виджету для изменения его состояния, по таймеру?
Иначе это всегда внешнее воздействие на EditorToolBar - через метод update, сигнал слот.

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

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

Пусть скорость линейная функция

v = v₀ + a_const*t
v - скорость
a - ускорение
t - время от начального момента

дистанция рассчитывается через интеграл (надеюсь понятно в такой записи)

d(t) = integral( v(t)dt, t₀, t);

если заменить расчет через delta_t, то получим

delta_t = t_i-t_i-1
d += v(t_i) * delta_t

реально же через интегралы

d += v(t_i) * delta_t + ( a_const * delta_t²) / 2

Чем больше delta_t тем больше ошибка.

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

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

Для подгона могу предложить только определять силу воздействия не по мгновенному значению, а по формуле

F₀ = F(t₀);
F₁ = F(t₁);

F = ( F₀ * w₀ + F₁ * w₁ ) / ( w₀ + w₁ );

и подбирать веса w, чтобы все выглядела достаточно прилично.

Это, скорее всего, из более раннего периода C++, когда отсутствовал auto в том виде, как он сейчас используется, и std::begin/std::end.

Наверное, без интегрирования все же не обойдется.
Задача о гравитационном взаимодействии двух тел имеет аналитическое решение (отталкивание - гравитация с отрицательным знаком).
Для трех и более - необходимо использовать численные методы, что в данном случае не оправдано.
Можно посмотреть в сторону моделирования частиц с помощью GPU (PhysX), там такие же задачи решаются.

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

Самое корректное решение будет, к тому же легко расширяемое.

Может в самом Value хранить итератор map2? Хорошего впечатления не производит... 
[/quote]

После изменения состава map2, хранимый итератор может стать невалидным.

Можно хранить в map2 shared_ptr< Value >, а в map1 weak_ptr< Value >, тогда удаление Value из map2 приведет к обнулению указателя weak_ptr в map1.
Только это кажется нерациональным, так как пустые weak_ptr "зависнут" в map1, но все зависит от контекста решаемой задачи.