Сообщение Re[8]: Возможна ли интеграция MSVS и Qt4? от 27.01.2016 18:38
Изменено 27.01.2016 18:42 AlexGin
Здравствуйте, SaZ, Вы писали:
SaZ>Здравствуйте, AlexGin, Вы писали:
AG>>...
AG>>Попутный вопрос: значит на все контейнеры Qt (QVector, QList, etc.) можно свободно "забить" и применять вместо них STL контейнеры?
SaZ>Все Qt контейнеры (включая строки) поддерживают COW. Причём, потокобезопасно. А вот для STL контейнеров придётся значительно больше думать. В том числе при размещении элементов, для которых не реализован конструктор перемещения. Я пока сам не особо владею навыками использования конструктора перемещения.
SaZ>Но, главный аргумент в пользу Qt контейнеров для Qt приложений это то, что Qt использует свои контейнеры внутри своего фреймворка. Нужно вам, например, получить список дочерних классов — вам вернут QList< QObject * >. Нужно получить или передать список строк, берётся QStringList. Потом, есть замечательный класс QVariant, который не имеет STL аналогов. Придётся тащить буст.
Это мне напоминает ситуацию с MFC — там также есть свои контейнеры, которые используются в библиотеке классов, однако мне (если не требовелось что-то спицифичное, что потребует работы с мфсишными контейнерами) было удобнее работать с STL контейнерами.
SaZ>Про контейнеры так же надо помнить, что есть различия. std::set хранит элементы в виде map, а QSet в виде хэш таблицы.
+100500
AG>>Ещё вопрос: насколько на сегодняшний день Qt поддерживает новые стандарты C++? (тот же C++11)
SaZ>С++ 11 поддерживается начиная с 5-й версии. Причём, если я не ошибаюсь, начиная с Qt 5.7 поддержка компиляторов С++03 будет или убрана совсем или получит статус deprecated.
SaZ>Реализован цикл for для всех Qt контейнеров (можно писать for ( auto text : stringList ) {...}. Активно пишутся конструкторы перемещения (за счёт их наличия значительно ускоряется работа со строками).
SaZ>Очень важная фича, это дополнительный синтаксис QObject::connect. Теперь сигналы и слоты передаются как указатели на методы, а не через строки, завёрнутые в макросы, и проверка совместимости сигнала и слота делается в compile-time, а не в runtime. Т.е. можно писать connect( button, &QPushButton::clicked, this, &MyWidget::onBtnClicked );, что выглядит намного лаконичнее (и лучше поддерживается всякими autocomplete утилитами, типа ReSharper'а).
SaZ>P.S. что на вскидку могу вспомнить, про нововведения в Qt5, которые надо помнить при переходе с Qt4.
SaZ>- Модуль Qt4Gui разделён на Qt5Gui + Qt5Widgets. Сделано это для лучшей модульности кода. Например, QStandardItemModel теперь лежит в QtGui, и может использоваться как в QtWidgets, так и в QtQuick. А вот уже виджеты не будут подгружаться, если вы используете QtQuick/QML для GUI.
SaZ>- Многопоточность частично вынесена в отдельный модуль QtConcurrent.
SaZ>- Сигналы стали public методами, а не protected, как было ранее.
SaZ>- По самим виджетам немного поменялись некоторые классы (например, по работе с шириной заголовков в QTreeView). Но это мелочи.
SaZ>- Сложнее стало делать платформозависимые вещи с виджетами. Например, у виджета убрали метод winEvent, попутно внеся пару багов.
SaZ>- qDebug, теперь макрос. Сделано это для того, чтобы можно было в обработчике использовать контекст, откуда было выведено сообщение (передаются __FILE__, __LINE__ и т.п.).
SaZ>Но в целом, много хороших и удобных нововведений, о которых лучше читать блог разработчиков.
Спасибо, уважаемый SaZ!
Огромное спасибо, земляк
SaZ>Здравствуйте, AlexGin, Вы писали:
AG>>...
AG>>Попутный вопрос: значит на все контейнеры Qt (QVector, QList, etc.) можно свободно "забить" и применять вместо них STL контейнеры?
SaZ>Все Qt контейнеры (включая строки) поддерживают COW. Причём, потокобезопасно. А вот для STL контейнеров придётся значительно больше думать. В том числе при размещении элементов, для которых не реализован конструктор перемещения. Я пока сам не особо владею навыками использования конструктора перемещения.
SaZ>Но, главный аргумент в пользу Qt контейнеров для Qt приложений это то, что Qt использует свои контейнеры внутри своего фреймворка. Нужно вам, например, получить список дочерних классов — вам вернут QList< QObject * >. Нужно получить или передать список строк, берётся QStringList. Потом, есть замечательный класс QVariant, который не имеет STL аналогов. Придётся тащить буст.
Это мне напоминает ситуацию с MFC — там также есть свои контейнеры, которые используются в библиотеке классов, однако мне (если не требовелось что-то спицифичное, что потребует работы с мфсишными контейнерами) было удобнее работать с STL контейнерами.
SaZ>Про контейнеры так же надо помнить, что есть различия. std::set хранит элементы в виде map, а QSet в виде хэш таблицы.
+100500
AG>>Ещё вопрос: насколько на сегодняшний день Qt поддерживает новые стандарты C++? (тот же C++11)
SaZ>С++ 11 поддерживается начиная с 5-й версии. Причём, если я не ошибаюсь, начиная с Qt 5.7 поддержка компиляторов С++03 будет или убрана совсем или получит статус deprecated.
SaZ>Реализован цикл for для всех Qt контейнеров (можно писать for ( auto text : stringList ) {...}. Активно пишутся конструкторы перемещения (за счёт их наличия значительно ускоряется работа со строками).
SaZ>Очень важная фича, это дополнительный синтаксис QObject::connect. Теперь сигналы и слоты передаются как указатели на методы, а не через строки, завёрнутые в макросы, и проверка совместимости сигнала и слота делается в compile-time, а не в runtime. Т.е. можно писать connect( button, &QPushButton::clicked, this, &MyWidget::onBtnClicked );, что выглядит намного лаконичнее (и лучше поддерживается всякими autocomplete утилитами, типа ReSharper'а).
SaZ>P.S. что на вскидку могу вспомнить, про нововведения в Qt5, которые надо помнить при переходе с Qt4.
SaZ>- Модуль Qt4Gui разделён на Qt5Gui + Qt5Widgets. Сделано это для лучшей модульности кода. Например, QStandardItemModel теперь лежит в QtGui, и может использоваться как в QtWidgets, так и в QtQuick. А вот уже виджеты не будут подгружаться, если вы используете QtQuick/QML для GUI.
SaZ>- Многопоточность частично вынесена в отдельный модуль QtConcurrent.
SaZ>- Сигналы стали public методами, а не protected, как было ранее.
SaZ>- По самим виджетам немного поменялись некоторые классы (например, по работе с шириной заголовков в QTreeView). Но это мелочи.
SaZ>- Сложнее стало делать платформозависимые вещи с виджетами. Например, у виджета убрали метод winEvent, попутно внеся пару багов.
SaZ>- qDebug, теперь макрос. Сделано это для того, чтобы можно было в обработчике использовать контекст, откуда было выведено сообщение (передаются __FILE__, __LINE__ и т.п.).
SaZ>Но в целом, много хороших и удобных нововведений, о которых лучше читать блог разработчиков.
Спасибо, уважаемый SaZ!
Огромное спасибо, земляк
Re[8]: Возможна ли интеграция MSVS и Qt4?
Здравствуйте, SaZ, Вы писали:
SaZ>Здравствуйте, AlexGin, Вы писали:
AG>>...
AG>>Попутный вопрос: значит на все контейнеры Qt (QVector, QList, etc.) можно свободно "забить" и применять вместо них STL контейнеры?
SaZ>Все Qt контейнеры (включая строки) поддерживают COW. Причём, потокобезопасно. А вот для STL контейнеров придётся значительно больше думать. В том числе при размещении элементов, для которых не реализован конструктор перемещения. Я пока сам не особо владею навыками использования конструктора перемещения.
SaZ>Но, главный аргумент в пользу Qt контейнеров для Qt приложений это то, что Qt использует свои контейнеры внутри своего фреймворка. Нужно вам, например, получить список дочерних классов — вам вернут QList< QObject * >. Нужно получить или передать список строк, берётся QStringList. Потом, есть замечательный класс QVariant, который не имеет STL аналогов. Придётся тащить буст.
Это мне напоминает ситуацию с MFC — там также есть свои контейнеры, которые используются в библиотеке классов, однако мне (если не требовелось что-то спицифичное, что потребует работы с мфсишными контейнерами) было удобнее работать с STL контейнерами. VARIANT — помню по технологии COM, похоже что в Qt используется та же идея универсального типа данных.
SaZ>Про контейнеры так же надо помнить, что есть различия. std::set хранит элементы в виде map, а QSet в виде хэш таблицы.
+100500
AG>>Ещё вопрос: насколько на сегодняшний день Qt поддерживает новые стандарты C++? (тот же C++11)
SaZ>С++ 11 поддерживается начиная с 5-й версии. Причём, если я не ошибаюсь, начиная с Qt 5.7 поддержка компиляторов С++03 будет или убрана совсем или получит статус deprecated.
SaZ>Реализован цикл for для всех Qt контейнеров (можно писать for ( auto text : stringList ) {...}. Активно пишутся конструкторы перемещения (за счёт их наличия значительно ускоряется работа со строками).
SaZ>Очень важная фича, это дополнительный синтаксис QObject::connect. Теперь сигналы и слоты передаются как указатели на методы, а не через строки, завёрнутые в макросы, и проверка совместимости сигнала и слота делается в compile-time, а не в runtime. Т.е. можно писать connect( button, &QPushButton::clicked, this, &MyWidget::onBtnClicked );, что выглядит намного лаконичнее (и лучше поддерживается всякими autocomplete утилитами, типа ReSharper'а).
SaZ>P.S. что на вскидку могу вспомнить, про нововведения в Qt5, которые надо помнить при переходе с Qt4.
SaZ>- Модуль Qt4Gui разделён на Qt5Gui + Qt5Widgets. Сделано это для лучшей модульности кода. Например, QStandardItemModel теперь лежит в QtGui, и может использоваться как в QtWidgets, так и в QtQuick. А вот уже виджеты не будут подгружаться, если вы используете QtQuick/QML для GUI.
SaZ>- Многопоточность частично вынесена в отдельный модуль QtConcurrent.
SaZ>- Сигналы стали public методами, а не protected, как было ранее.
SaZ>- По самим виджетам немного поменялись некоторые классы (например, по работе с шириной заголовков в QTreeView). Но это мелочи.
SaZ>- Сложнее стало делать платформозависимые вещи с виджетами. Например, у виджета убрали метод winEvent, попутно внеся пару багов.
SaZ>- qDebug, теперь макрос. Сделано это для того, чтобы можно было в обработчике использовать контекст, откуда было выведено сообщение (передаются __FILE__, __LINE__ и т.п.).
...интересно...
SaZ>Но в целом, много хороших и удобных нововведений, о которых лучше читать блог разработчиков.
Спасибо, уважаемый SaZ!
Огромное спасибо, земляк
SaZ>Здравствуйте, AlexGin, Вы писали:
AG>>...
AG>>Попутный вопрос: значит на все контейнеры Qt (QVector, QList, etc.) можно свободно "забить" и применять вместо них STL контейнеры?
SaZ>Все Qt контейнеры (включая строки) поддерживают COW. Причём, потокобезопасно. А вот для STL контейнеров придётся значительно больше думать. В том числе при размещении элементов, для которых не реализован конструктор перемещения. Я пока сам не особо владею навыками использования конструктора перемещения.
SaZ>Но, главный аргумент в пользу Qt контейнеров для Qt приложений это то, что Qt использует свои контейнеры внутри своего фреймворка. Нужно вам, например, получить список дочерних классов — вам вернут QList< QObject * >. Нужно получить или передать список строк, берётся QStringList. Потом, есть замечательный класс QVariant, который не имеет STL аналогов. Придётся тащить буст.
Это мне напоминает ситуацию с MFC — там также есть свои контейнеры, которые используются в библиотеке классов, однако мне (если не требовелось что-то спицифичное, что потребует работы с мфсишными контейнерами) было удобнее работать с STL контейнерами. VARIANT — помню по технологии COM, похоже что в Qt используется та же идея универсального типа данных.
SaZ>Про контейнеры так же надо помнить, что есть различия. std::set хранит элементы в виде map, а QSet в виде хэш таблицы.
+100500
AG>>Ещё вопрос: насколько на сегодняшний день Qt поддерживает новые стандарты C++? (тот же C++11)
SaZ>С++ 11 поддерживается начиная с 5-й версии. Причём, если я не ошибаюсь, начиная с Qt 5.7 поддержка компиляторов С++03 будет или убрана совсем или получит статус deprecated.
SaZ>Реализован цикл for для всех Qt контейнеров (можно писать for ( auto text : stringList ) {...}. Активно пишутся конструкторы перемещения (за счёт их наличия значительно ускоряется работа со строками).
SaZ>Очень важная фича, это дополнительный синтаксис QObject::connect. Теперь сигналы и слоты передаются как указатели на методы, а не через строки, завёрнутые в макросы, и проверка совместимости сигнала и слота делается в compile-time, а не в runtime. Т.е. можно писать connect( button, &QPushButton::clicked, this, &MyWidget::onBtnClicked );, что выглядит намного лаконичнее (и лучше поддерживается всякими autocomplete утилитами, типа ReSharper'а).
SaZ>P.S. что на вскидку могу вспомнить, про нововведения в Qt5, которые надо помнить при переходе с Qt4.
SaZ>- Модуль Qt4Gui разделён на Qt5Gui + Qt5Widgets. Сделано это для лучшей модульности кода. Например, QStandardItemModel теперь лежит в QtGui, и может использоваться как в QtWidgets, так и в QtQuick. А вот уже виджеты не будут подгружаться, если вы используете QtQuick/QML для GUI.
SaZ>- Многопоточность частично вынесена в отдельный модуль QtConcurrent.
SaZ>- Сигналы стали public методами, а не protected, как было ранее.
SaZ>- По самим виджетам немного поменялись некоторые классы (например, по работе с шириной заголовков в QTreeView). Но это мелочи.
SaZ>- Сложнее стало делать платформозависимые вещи с виджетами. Например, у виджета убрали метод winEvent, попутно внеся пару багов.
SaZ>- qDebug, теперь макрос. Сделано это для того, чтобы можно было в обработчике использовать контекст, откуда было выведено сообщение (передаются __FILE__, __LINE__ и т.п.).
...интересно...
SaZ>Но в целом, много хороших и удобных нововведений, о которых лучше читать блог разработчиков.
Спасибо, уважаемый SaZ!
Огромное спасибо, земляк