Xtoman 10 December 2020 at 13:55

Вышла версия 6.0 фреймворка Qt

Programming *

+14

8.4K

Comments 11

Emulyator 10.12.2020 at 15:24

Официально 7-ка (Windows 7) не поддерживается, но люди пишут, что вроде на ней работает. Чем грозит разработка на 7-ке?

akaAzazello 10.12.2020 at 16:10

Если у вас настроенная система Win7 с компилятором С++17, cmake и D3D11/VK/GL драйверами — то с разработкой будет всё в норме.
А вот официальной поддержки разрабатываемого вами продукта на Win7 не будет;)

upd: На уровне кода Qt 6, полагаю, сможет работать и на Win2k — а вот с более ранними (т.е. до WinNT 3.51) уже будут сложности — но связанны они больше с драйверами для отрисовки будут (нет D3D и VK, и, местами, даже OpenGL 2.х). Ну и систему сборки/компиляторы придётся для начала завести;)

kuzulis 18.12.2020 at 15:16

> На уровне кода Qt 6, полагаю, сможет работать и на Win2k

Наврятли, т.к. там изменения не только связанные с отрисовкой. Начиная с версии 5.7 (если не ошибаюсь), минимальная версия Windows это 5.7. Там изменения, как минимум коснулись с работой с сетью, там используется теперь Win API из Windows 7 (которых нету в XP и ниже). Может и еще где что-то «обновили», не знаю… Я бы не надеялся на все что ниже 7-ки ))

akaAzazello 10.12.2020 at 15:49

Мне кажется, вы перепутали IDE (QtCreator — сейчас в состоянии RC для 4.14) и SDK(сама Qt, действительно вышедшая недавно в версии 6.0).

Кроме того, часть описанных вами особенноcтей 6.0 также относится к ветке 5.х (как «новая графическая архитектура» — это RHI(5.12) или «система сборки для приложений»(в 6.0 — сборка самой SDK)) или даже 4.х — как сборка для микроконтроллеров.

upd: Мне кажется важным также упомянуть, что не все модули(которые не legacy) из 5.х поддерживаются прямо сейчас — часть будет портирована лишь в 6.1 и 6.2 LTS(т.е. ориентировочно — сентябрь 2021) — вот тут полный список

Xtoman 10.12.2020 at 18:53

действительно ошибся с IDE и фреймворком, спасибо за замечание

DrSavinkov 11.12.2020 at 07:40

Лучше бы они починили работу с OpenMP — на днях писал программу, в которой надо было много раз в цикле модифицировать данные в QVector<QVector< double >> переменной. Так вот, попытка обернуть цикл в #pragma omp parallel for привела к падению при исполнении. Пришлось заменить на std::vector<std::vector< double >>, всё завелось с первого раза без ошибок.

Unrul 13.12.2020 at 13:51

QVector в QT5 использует COW семантику. Соответственно, там нужно быть осторожным с итераторами doc.qt.io/qt-5/containers.html#implicit-sharing-iterator-problem Может быть у вас из-за этого проблема?

DrSavinkov 13.12.2020 at 18:55

О, там не использовались итераторы. Там был код навроде

const int N = ...;
const double dt = ...;
QVector<QVector<double>> data(N, QVector<double>(N, 0.));
... // some manipulations with data, size unchanged
QVector<QVector<double>> changed_data = data;
#pragma omp parallel for
for(int i = 0; i < data.size(); i++)
  for(int j = 0; j < data[i].size(); j++)
    changed_data[i][j] = data[i][j] + ((i ? data[i-1][j] : 0.) + (i < N-1 ? data[i+1][j] : 0.) + (j ? data[i][j-1] : 0.) + (j < N-1 ? data[i][j+1] : 0.) - 4 * data[i][j]) * dt;

Unrul 14.12.2020 at 00:43

В общем, в QT потокобезопасен только подсчёт ссылок на общие данные. Само копирование при изменении происходит без какой-либо защиты, поэтому такие классы можно только безопасно читать из разных потоков. То есть, это не проблема OpenMP, это проблема семантики CoW классов в QT. Можно или не использовать такие классы, или подправить предыдущий код:

QVector<QVector<double>> data(N, QVector<double>(N, 0.));
...
QVector<QVector<double>> changed_data = data;
changed_data.detach();
for(auto& v: data) v.detach();
for(auto& v: changed_data) v.detach();
...