Доступна предварительная сборка Qt 6.0

Деньги теперь надо платить?

Скажите кто знает, есть шанс что Qt смигрирует на другой язык? Или их плюсы устраивают?

Примерно такая же, как лтс версии бесплатно.

есть шанс что Qt смигрирует на другой язык?

Конечно. Они уже давно на rust переходят. На С++ осталось только всякое легаси...

MOC-костыль с сишной макроснёй под нож пошёл?

На дворе 2020 год, а там всё

#define Q_OBJECT \
public: \
    QT_WARNING_PUSH \
    Q_OBJECT_NO_OVERRIDE_WARNING \
    static const QMetaObject staticMetaObject; \
    virtual const QMetaObject *metaObject() const; \
    virtual void *qt_metacast(const char *); \
    virtual int qt_metacall(QMetaObject::Call, int, void **); \
    QT_TR_FUNCTIONS \
private: \
    Q_OBJECT_NO_ATTRIBUTES_WARNING \
    Q_DECL_HIDDEN_STATIC_METACALL static void qt_static_metacall(QObject *, QMetaObject::Call, int, void **); \
    QT_WARNING_POP \
    struct QPrivateSignal {}; \
    QT_ANNOTATE_CLASS(qt_qobject, "")

/* qmake ignore Q_OBJECT */
#define Q_OBJECT_FAKE Q_OBJECT QT_ANNOTATE_CLASS(qt_fake, "")

#ifndef QT_NO_META_MACROS
/* qmake ignore Q_GADGET */
#define Q_GADGET \
public: \
    static const QMetaObject staticMetaObject; \
    void qt_check_for_QGADGET_macro(); \
    typedef void QtGadgetHelper; \
private: \
    QT_WARNING_PUSH \
    Q_OBJECT_NO_ATTRIBUTES_WARNING \
    Q_DECL_HIDDEN_STATIC_METACALL static void qt_static_metacall(QObject *, QMetaObject::Call, int, void **); \
    QT_WARNING_POP \
    QT_ANNOTATE_CLASS(qt_qgadget, "") \
    /*end*/

/* qmake ignore Q_NAMESPACE_EXPORT */
#define Q_NAMESPACE_EXPORT(...) \
    extern __VA_ARGS__ const QMetaObject staticMetaObject; \
    QT_ANNOTATE_CLASS(qt_qnamespace, "") \
    /*end*/

/* qmake ignore Q_NAMESPACE */
#define Q_NAMESPACE Q_NAMESPACE_EXPORT() \
    /*end*/

требует поддержки C++17 от компилятора, поэтому разработка фокусируется на сравнительно недавно выпущенных компиляторах.

Это гцц 7, в принципе не такой уж и новый, от 2017-2018 года, но на самом деле даже в гцц ещё не всё поддерживается, в шланге ещё не всё доделали, в последнем только частичная поддержка. Но им наверное и не надо 100%.

А кто-то кутэ использует не на локалхосте, компиляторы с с++17 есть в наличии? Как там вообще с портируемостью сейчас обстоят дела?

Скажите кто знает, есть шанс что Qt смигрирует на другой язык? Или их плюсы устраивают?

Есть рекомендация, чтобы портировали на C#. Там Qt не хватает, ну и это необходимо для повышения популярности Qt.

C# - это легаси, надо мигрировать на vala с с-апи, это будущее.

А кто-то кутэ использует не на локалхосте, компиляторы с с++17 есть в наличии? Как там вообще с портируемостью сейчас обстоят дела?

Тут палка о двух концах. С одной стороны Qt 5 действительно легко портировать на любую микроволновку, благодаря внедрению QPA.

Умельцам даже Qt на GTK+ портировать удалось: https://github.com/CrimsonAS/gtkplatform, и это может иметь какой-то смысл, учитывая что X.Org вместе со своими костылями вроде Xlib и XCB объявлен устаревшим, а GTK+ на сегодня по сути дефолтный графический тулкит в Linux. Возможно в будушем Qt примет этот QPA-модуль себе в upstream вместо устаревшего QPA-модуля XCB и этот шаг поможет решить проблему мимикрирования одних тулкитов под другие в Linux и превратит Qt в сахарок над более низкоуровневым GTK+, как сейчас Qt сахарок над XCB или QtWayland.

Но с другой стороны, фреймворк постоянно поднимает стандарты и если раньше условный C++98, на котором был написан Qt, был доступен на каждом чайнике, то сегодня на старом железе, которое забросили вендоры, использовать Qt новых версий будет трудно или вообще невозможно.

Но не стоит забывать, что мы живём в эпоху, когда Linux победил и все коммерческие UNIX’ы вроде AIX/HP-UX/Solaris/SCO Unix и иже с ними отправлены на свалку истории, и даже порты на RTOS вроде INTEGRITY, QNX и VxWorks потеряли свою актуальность. Захожу на страничку официальной документации и вижу:

If you are interested in later Qt releases, please contact Qt professional services.

https://doc.qt.io/qt-5/vxworks.html

Собственно Linux даже на Embedded по сути победил. А раз он победил, значит никаких проблем заюзать GCC 7 или Clang/LLVM с поддержкой C++17 на новых платках и нету. Разве что если у тебя будет что-то очень-очень старое.

Я спрашивал у тех кто использует не на локалхосте. Когда гтк сможет использовать другой тулкит в качестве бекэнда, тогда и расскажешь что-нибудь про объявления на заборах.

Тебе его макросная натура спать мешает? Открою секрет, руст вон вообще ВЕСЬ в макросах.

https://users.rust-lang.org/t/macro-rules-resolution-hell/40236

Весь Qt вряд ли когда-нибудь смигрирует с C++. Но вот надежда, что пребывающие в стагнации QtCore и QtWidgets сама компания или энтузиасты перепишут на тот же Rust – есть.

Ага, а лисп так вообще из одних макро и состоит.

Макрос-макросу рознь. Не следует сравнивать макросы в C/C++ и Rust. В случае первого на уровне лексера/препроцессора используется банальнейшая автоподстановка, а в случае второго это полноценная модификация AST, в результате чего макросы гигиенические и не несут опасности для окружающего кода. К тому же в Qt вся эта макросня приправлена отдельным MOC-костылём, который проходит по каждому исходнику ища в нём Q_OBJECT и дрищет нечитаемыми портянками, которые дополнительно компилируются и линкуются с твоей программой. Просто омерзительно.

Там опять совместимость API не поломали? А то недавно пришлось чинить программу написанную под Qt4.

Но вот надежда, что пребывающие в стагнации QtCore и QtWidgets

Какие с ними проблемы? Или нужно постоянно что-то менять для имитации бурной деятельности?

Пацаны, ваша проблема в том, что вы не умеете программировать, а щеки надуваете так как будто умеете, и ктото не знающий кто вы такие может принять ваши высеры за истину. В с++ есть constexpr и consteval, и это не модификация текста в каком-то виде, а вычисления во время компиляции примерно как в Лиспе. Но это все все равно не может сделать даже половины того что может сделать элементарный препроцессор.

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

на старом железе, которое забросили вендоры Разве что если у тебя будет что-то очень-очень старое.

Только поддержка и багофиксы. Железо заброшенное вендорами… Можешь привести примеры такого, где может потребоваться актуальная версия Qt? На котором планируется разработка нового проекта?

DIY проекты на барахле с АлиЭкспресса не в счёт.

дрищет нечитаемыми портянками, которые дополнительно компилируются и линкуются с твоей программой.

Это ещё пример не самой худшей кодогенерации.

Нет конечно. Там почти 6 лямов кода.

Именно поэтому предлагается static reflection и generative metaprogramming. Но они, скорее всего, не раньше 26х будут.

C++17 объявлен полностью поддерживаемым в gcc9. Недавно уже 10й вышел. Для не локалхоста не нужно всю систему переделывать, достаточно только собрать компилятор, который там запустится (ну и может стандартную библиотеку допилить. Компилятор вполне может быть кросс-компилятором, поэтому разрабатывать для baremetal arm вполне можно и на c++20. Главное, чтобы бакенд не дропнули (такое случается и в gcc для барахла). Даже если бакенд дропнули, или его не было, можно взять хороший фронтенд и дописать, например, для того же llvm. Или взять edg, который C может генерировать. Так что нет причин тянуть «портабилити», только усложняя разработку.

Так что, будут пилить шестую плазму? Сколько будут поддерживать Qt5 после выхода Qt6?

Скажите кто знает, есть шанс что Qt смигрирует на другой язык? Или их плюсы устраивают?

Но… зачем??? Кому в каком горячечном бреду может понадобиться мигрировать с плюсов?

Rust не готов, добавлять зависимость от жирного уродского рантайма net или jvm смысла нет, ибо просто electron возьмут, кому нативное не нужно. Ocaml и вообще ml не популярны. Т.е. кроме первого варианта остальное и рассматривать не стоит.

Но не стоит забывать, что мы живём в эпоху, когда Linux победил и все коммерческие UNIX’ы вроде AIX/HP-UX/Solaris/SCO Unix и иже с ними отправлены на свалку истории,

как припекает-то до сих пор - загляденье

Тем временем из системы только-только удалились библиотеки Qt4.
Совместимость-то хоть не поломают? Нового переписывания кеды не переживут.

Макросы в Lisp и C++ очень разные. Это не одно и то же

В этом и был смысл моего сообщения. Прочитай то, на которое я отвечал.

Просто объявили бы Qt устаревшим и призвали разработчиков переходить на GTK.

Переходить с Мицубиcи в сборе на кузов от Ниссана, ага.

В очередной раз повторяю: GTK — графический тулкит, Qt — фреймворк, включая кучу библиотек и систему сборки. Аналог GTK — это QtGui+QtWidgets.

P.S. Против GTK как таковой ничего не имею, кому нравится на ней писать — пусть пишет. Вот только считать свой инструмент единственно правильным — один Apple у нас уже есть.

А когда там будет новый гтк 4 готов, кто скажет?

Осенью этого года

В блоге по ссылке, похоже, ЛОР-эффект…

Кстати, QTextCodec таки выкинули, как грозились?

Собственно Linux даже на Embedded по сути победил. А раз он победил, значит никаких проблем заюзать GCC 7 или Clang/LLVM с поддержкой C++17 на новых платках и нету. Разве что если у тебя будет что-то очень-очень старое.

да китайцы до сих пор поставляют gcc-4.9 в лучшем случае, казалось бы не такой старый, но даже на Qt-5.12 есть «особенности», а Qt-5.15 вообще не собирается, требуется constexpr конструкторы насколько я понял

Можешь привести примеры такого, где может потребоваться актуальная версия Qt? На котором планируется разработка нового проекта?

любой Qt-программист предпочтёт использовать максимально свежую сборку, так как работать с legacy в виде Qt-4.7.3 без stl они не могут/не хотят :)

Ну так имеются сторонние библиотеки, фреймворки ненужны! (111)

Qt — фреймворк, включая кучу библиотек и систему сборки

На чём в этом фреймворке пишут? Javascript, PHP, C#?

DIY проекты на барахле с АлиЭкспресса не в счёт.

А я про них как раз.

Ты вроде в теме, напомни пожалуйста в какой версии Qt перестал собираться компилятором который поддерживает только C++98 (C++03)?

Ну так имеются сторонние библиотеки, фреймворки ненужны! (111)

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

За кросплатформой нужно идти в веб.

С чего это вдруг? Кому нужно пусть и идет.

Может серверное ПО тоже через веб делать? Да и многое веб не умеет, например как там организовать обмен через RS485? MQTT? Работа с базами данных?

не могу утверждать до версии, но Qt5 вроде уже требуется C++11

А он переставал? По-моему все фишки С++11 до сих пор отключаемы. Edit: хотя не, я не прав, прямо в QObject есть std::enable_if безо всяких условий исключения этого кода.

C++ и по желанию QML, а что?

Не, ты чего. Они 98-ой тянули очень-очень долго.

Тут нашёл:

Leveraging C++11

The core of Qt comes from its C++ foundation and the powerful native performance it offers you. We of course always want to ensure Qt is on top of the latest C++ developments, so that the framework continues to grow with your needs. Qt has supported the use of C++11 in application code for a long time. We also wanted to keep supporting C++98 compilers up to Qt 5.6, which meant that we needed to wait before fully leveraging C++11 features in the Qt framework libraries themselves.

Starting with Qt 5.7 all compilers are C++11 compatible, which allows us to start using new C++ functionality such as auto, lambda and many more in Qt itself. These features will also start to appear in the Qt API, where it makes sense to do so. For those who can’t move yet the long term supported Qt 5.6 provides full C++98 compatibility.

https://www.qt.io/blog/2016/04/21/qt-5-7-beta-released

зам фреймворками будущее: https://i.imgur.com/6j2WmHB.png

Qt 5.6 LTS официально последняя версия, которую можно собрать компилятором с C++98/03 стандартом. Она же и последняя работающая на Windows XP :^)

changes-5.7.0

•                    Important Behavior Changes                        *
  

• Starting with Qt 5.7, Qt requires a C++11 compiler with support for C++11 atomics. This affects user code too: Qt headers no longer compile with a C++98 compiler. The minimum compiler versions for this release are:
  • GCC 4.7
  • Clang 3.4 (found in XCode 5.1)
  • Microsoft Visual Studio 2013

несколько двояко, но проверять не буду

скажем для Qt-5.15 они поддерживают C++11, но с некими неявными ограничениями, странно то, что в самом коде они проверяют версии от GCC-4.3 и не выходят с ошибкой при обнаружении оного, повидимому руки не дошли поправить