Здесь недостаточно условий.
Точка и нормаль определяют плоскость. Наверное эта точка является началом координат системы x',y' (или нет?). Куда направлены сами оси x' и y' ? Нужно как минимум центр, два вектора и условия для системы координат (правосторонняя/левосторонняя, прямоугольная декартова).

Если не изменяет память, изначально вопрос состоял как-то так


Почему тогда обсуждаем Qt signal-slot, его возможности и преимущества?

Не могу понять предмет спора. Чей подход лучше? По мне, так нет никакой разницы, каждый опирается на свои требования к коду и конкретизацию задачи.
Передали this - получили гибкость, скорость, вязкость кода и проблемы при асинхронной работе (необходимость синхронизации).
Реализовали через signal-slot - получили модульность, больше кода, небольшую приторможенность (в GUI совсем незаметную), возможное копирование данных, неудобство взаимосвязи между объектами разных иерархических уровней.
Взяли за основу, например, конечные автоматы - получили другие достоинства и недостатки.
Можно реализовать и через периодический опрос загрузчика по таймеру со своим геморроем.

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

Если требование - решить задачу за 5 минут при том со всеми фенечками, то загрузчик вообще будет частью диалога и вся реализация будет в одном файле. Если нужна асинхронная загрузка от GUI, то, например, использование this уже будет не удобно и будет ваяться concurrent, signal-slot, model-controller-view их суперпозиция или еще что-то. Нет единственно верного подхода, и в любой работе всегда действует правило треугольника время - качество - ресурсы, всего должно быть достаточно, а идеальный случай недостижим.

Здесь важно, чем собраны libthriftnb и libthrift. Скорее всего с помощью MSVC.
При использовании MinGW32 эти библиотеки необходимо собрать самостоятельно, как это сделать в Linux описано здесь http://thrift.apache.org/docs/BuildingFromSource, про Windows к сожалению не знаю.

Как раз сигнал слот не священен Это просто более гибкий механизм взаимодействия, чем паттерн наблюдателя, так как не требует прямых или косвенных взаимосвязей между типами объектов, участвующих во взаимодействии.
Если говорить о реализации сигнал-слот взаимодействия в Qt, то наследование от QObject - ооочень неудачное решение), но это всего лишь одна из возможных.

Вариантов решения масса, все зависит от дополнительных требований.

1. Синхронная или асинхронная работа компонентов (например, загрузчика и графического интерфейса).
2. Событийная или распределенная модель обмена данными.
3. Модульность

Эти требования определяют выбор паттерна, который целесообразно использовать.

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

Самый простой и быстрый вариант (с нуля) - синхронная событийная модель, которая в зависимости от необходимой модульности (возможной "вязкости" кода) может быть сведена:
- к явным вызовам API одного компонента из другого (подавляющее число реализаций, плохо сопровождаемый код),
- к модели наблюдателя (подписка на события, уже лучше),
- к модели сигнал-слот boost, Qt (взаимосвязь независимых модулей, еще лучше),
- к чему-те еще

Все варианты правильные, выбор зависит от разработчика (его опыта) и решаемой задачи.

Если задача комплексная (например, загрузка файлов мешает отображению GUI и/или наоборот), то необходимо уже смотреть в сторону асинхронной модели поведения

- асинхронный сигнал слот
- модель актеров
- активные объекты
- что-то еще

выбор за Вами ...

Так линковки с библиотеками apache http://thrift.apache.org/lib/cpp

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

Здесь необходимо либо править непосредственно исходники Qt, либо все писать самому, либо вытаскивать код из Qt, объявив его в другом пространстве имен, чтобы не было конфликтов при линковке.

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

Я собирал проект Qt 4.7.4 с помощью mingw-w64 https://sourceforge.net/projects/mingw-w64/ версия x86_64-5.3.0-posix-seh-rt_v4-rev0
Есть небольшие особенности).

Мои ремарки по сборке 64 бит. Пришлось отключить tiff и поправить исходники.


Изменения в исходных кодах

./src/corelib/tools/qsimd.cpp

поменять в строке 288

C++ (Qt)
#if defined(Q_CC_GNU)
    quint64 tmp;
    asm ("xchg %%rbx, %1\n"
         "cpuid\n"
         "xchg %%rbx, %1\n"
        : "=c" (feature_result), "=&r" (tmp)
        : "a" (1)
        : "%edx"
        );
#elif defined (Q_OS_WIN64)
    {
       int info[4];
       __cpuid(info, 1);
       feature_result = info[2];
    }
#endif
 

вместо

C++ (Qt)
#if defined (Q_OS_WIN64)
    {
       int info[4];
       __cpuid(info, 1);
       feature_result = info[2];
    }
#elif defined(Q_CC_GNU)
    quint64 tmp;
    asm ("xchg %%rbx, %1\n"
         "cpuid\n"
         "xchg %%rbx, %1\n"
        : "=c" (feature_result), "=&r" (tmp)
        : "a" (1)
        : "%edx"
        );
#endif
 

Весь проект собирается.

Надо отметить, что QtCreator 32 bit не дружит с qmake 64 bit, его также необходимо пересобрать в 64 битной версии, или пользоваться командной строкой.

Можно сделать, например, так

C++ (Qt)
void MyView::mouseMoveEvent(QMouseEvent* event) {
    QGraphicsView::mouseMoveEvent(event);
    // уже обработано
    if ( event->isAccepted() )
        return;
 
    if( event->buttons() & Qt::LeftButton )
    {
        addOffset( event->pos() - previousPoint );
        updateTransform( scale(), offset() );
    }
    previousPoint = event->pos();
}
 

А в обработчике событий item помечать событие event->accept();

Если требуется гарантия, то только так. И ни так уж это обременительно, как кажется. А если пользоваться, например, TCP/IP, то это гарантирует сам протокол.

Обычно этого в подавляющем большинстве случаев достаточно. Либо используют что-то типа xml.

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

Проверять необходимо пакет данных, который может представлять собой файл, пакет TCP|UDP и др. Анализирует содержимое пакета соответствующий парсер.
Для этого пакет должен иметь внутри встроенный механизм определения корректности/целостности данных. К ним относятся различные виды контрольных сумм, магические числа (для определения, например, формата данных) и любая другая информация.

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

Можно любую программу запустить на исполнение, поместив ее в файл скрипта или в виде текста содержимого скрипта, но... как уже писали программно нельзя ввести пароль.
Можно использовать доступ через sudo или ssh, однако в любом случае заранее необходимо будет зарегистрировать доступ к su.

А так правильный способ -