Тестовое задание на программиста С++/Qt компания некстерс

[ssoft]

Нет. Если элементы ветвей могут перекрываться - не может. А именно про это идет речь. Qt изначально умел рисовать все сам в frame buffer (что являлось его огромным плюсом), поэтому он сам является тем оконным композитором, который должен все отобразить. А это, для перекрывающихся виджетов, можно сделать только в один поток.

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

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

Это реализация иерархии отображаемых объектов в виде неотъемлемой части рендерера). А как же модель данных и возможность отображения их одновременно в разных видах? И если говорить относительно принципов построения GUI в Qt, то иерархия там представлена отношением Parent/Child, где дочерние элементы являются частью родительского, а не рендерера.

Ok, с отображением вопросы отпали, остались с реакцией.
А что в Qt принципиально не позволяет сделать независимую реакцию элементов?

Принципиально можно переделать всё). Напишу, что мешает в Qt C++, QML здесь не касаюсь.

• Во-первых, иерархия объектов в виде Parent/Child позволяет осуществлять непосредственный доступ по незащищенному голому указателю, как к родителю, так и дочерним элементам.
• Во-вторых, иерархия объектов в виде Parent/Child реализует взаимосвязь, когда родитель управляет временем жизни дочерних элементов.
• Во-третьих, иерархия объектов в виде Parent/Child и прямой доступ к родительскому и дочерним элементам требует обеспечения "правильного" порядка обработки событий (например, сначала HoverLeave для одного, затем HoverEnter для другого, а не вразнобой), иначе взаимосвязанные элементы дерева будут находиться в несогласованном состоянии.
• Во-четвертых, система фильтрации событий QEvent, которая позволяет напрямую перехватывать сообщения, и может быть использована в том числе в отношении один фильтр ко многим GUI.

Чтобы все это работало без проблем, вводится ограничение, чтобы все дерево иерархии Parent/Child соотносилось с одним потоком обработки сообщений. Может я еще что-то не написал, но все вышеперечисленное относится к базовым концепциям библиотеки Qt и переделывать это никто не будет).

Чтобы реализовать многопоточный GUI необходимо иметь иерархию в виде дерева независимых элементов, без отношения Parent/Child; желательно пользоваться не голыми указателями, а хотя бы shared/weak для контроля времени жизни GUI; изменить систему фильрации - вместо объектов использовать функторы, например; желательно не иметь явного соотношения GUI с потоком обработки, а гарантировать активность GUI не более чем в одном потоке.

[Old]

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

Вот как раз в современном GUI альфа канал обязателен, а вот 3-х мерные трансформации не очень. Надеюсь пока.

Это реализация иерархии отображаемых объектов в виде неотъемлемой части рендерера). А как же модель данных и возможность отображения их одновременно в разных видах? И если говорить относительно принципов построения GUI в Qt, то иерархия там представлена отношением Parent/Child, где дочерние элементы являются частью родительского, а не рендерера.

Дочерние являются частью родительского и легко могут рисоваться в других потоках, а вот top-level окна как раз являются элементами рендерера, и  именно он их отображает, и только в один поток. Еще раз напомню, Qt изначально умел рисовать все сам в frame buffer и этот рендерер иметь был обязан.

Чтобы все это работало без проблем, вводится ограничение, чтобы все дерево иерархии Parent/Child соотносилось с одним потоком обработки сообщений. Может я еще что-то не написал, но все вышеперечисленное относится к базовым концепциям библиотеки Qt и переделывать это никто не будет).

Да не надо ничего переделывать.
Qt не является (и наверное не задумывался), как многопоточный GUI (в том виде, как вы его видите).
Но на нем можно решать задачи многопоточного GUI, с ограничениями, оговорками, но можно. Нет нужды постоянно создавать и уничтожать виджеты из разных потоков, но бывает потребность рендерить виджет в другом потоке - в Qt это возможно. Нужна быстрая реакция на спонтанные события, не выполняйте "тяжелую" обработку в главном потоке. И т.д.

Если вам ехать, а не шашечки, то Qt можно для этого помучить. Это будет не так безопасно и красиво, но работать будет.

[ssoft]

 

Если вам ехать, а не шашечки, то Qt можно для этого помучить. Это будет не так безопасно и красиво, но работать будет.

Согласен, для статической структуры GUI будет работать и так, но к сожалению это не мой случай  . В моих задачах (связаны с почти realtime регистрацией наблюдений) постоянно меняется как состав данных, так и их атрибуты, да и к тому же GUI является частью 3D сцены, так что 3D трансформации уже рулят  .

[__Heaven__]

Ребят, а в 7, ведь не от компиля зависит, вроде как.
У нас конструктор копирования может быть вызван неявным образом, отсутствует указание explicit.
Также конструктор копирования применяется для создания объекта, а оператор присваивания работает с существующим объектом.
В нашем же случае объект создаётся, потому и происходит вызов копирования.

Но, признаться честно, до сегодняшнего дня я думал, что сначала создаётся объект, а потом производится вызов оператора присваивания.
Поправьте меня, если я не прав.

[Alex Custov]

Но, признаться честно, до сегодняшнего дня я думал, что сначала создаётся объект, а потом производится вызов оператора присваивания.
Поправьте меня, если я не прав.

Насколько я помню, могу ошибаться, это implementation-defined с упором на зависимость от уровня оптимизации. Простейшие конструкции типа A a = f(); из задания (при этом f() - тоже простейшая) оптимизатор может заменить на прямое конструирование.

[__Heaven__]

Эта штука называется copy initialization

[__Heaven__]

И на закуску
https://ideone.com/yAanDi

Код

C++ (Qt)
#include <iostream>
 
class A{
	public:
	A(){}
	explicit A(const A &other){ std::cout << "Copy\n";}
	~A(){}
 
	A &operator= (const A &other){
		std::cout << "Assign\n";
		return *this;
	}
};
 
 
int main() {
	A foo;
	A bar = foo;
	bar = foo;
	return 0;
}

prog.cpp: In function 'int main()':
prog.cpp:18:10: error: no matching function for call to 'A::A(A&)'
  A bar = foo;
          ^
prog.cpp:5:2: note: candidate: A::A()
  A(){}
  ^
prog.cpp:5:2: note:   candidate expects 0 arguments, 1 provided

Убрав explicit получим copy assign

[nsxwrs]

Вообще, знать что выдаст конструкция ++i + ++i + i++ это охренительно важно для работы программистом.
Избегать таких конструкций и писать, чтоб всё было однозначно ни в коем случае нельзя.
C начальным значением 0 получается 5, а при его отсутствии - 0. Кто объяснит почему?
https://ideone.com/6jSkPO

[kambala]

первый случай объясняется элементарно при знании работы операторов инкремента: 1 + 2 + 2; во втором случае результат неопределен, т.к. начальное значение — мусор (произвольное число).

[kai666_73]

Вообще, знать что выдаст конструкция ++i + ++i + i++ это охренительно важно для работы программистом.
Избегать таких конструкций и писать, чтоб всё было однозначно ни в коем случае нельзя.
C начальным значением 0 получается 5, а при его отсутствии - 0. Кто объяснит почему?
https://ideone.com/6jSkPO

Формально, результат этой конструкции undefined
и, соответственно, за использование подобных конструкций программисту надо руки отрубать... и ноги, на всякий случай )

[Авварон]

Я мимокрокодил, но хочу добавить, что в 7 ещё и RVO применилась, что не всегда бывает.