3 ms·

Qt's Contributor Summit just ended, and one of the topics was C++11 support [0]. The key takeaway is Qt 5.6 will start the move away from C++98 towards C++11 su

by cjslep 11y ago

Qt's Contributor Summit just ended, and one of the topics was C++11 support [0]. The key takeaway is Qt 5.6 will start the move away from C++98 towards C++11 support, though not fully C++11 mainly due to the MSVC compiler's limitations. The joy of being cross-platform. That being said, I don't immediately see the value of using CS over Qt. Binary size alone is not generally worth jumping ship from an established community. I'm also not sure why you would replace moc with template magic - moc will generally not fail (or will tell you if, say, you forgot to inherit from QObject), whereas template errors are midæval latin on a good day. The source files generated by moc have a lower bar to read through its generated code (making the Qt framework more accessible and seem less like magic), whereas templates require a very good understanding of metaprogramming (which is a less common skill). Also the 4.8 pick was an odd choice. Many significant changes that happened to 5.0 were made from a maintenance standpoint. Or "lowering technical debt" if you are playing buzzword bingo. Of all the issues, this is the biggest one in my opinion. [0] http://wiki.qt.io/QtCS2015_ModernCpp http://wiki.qt.io/QtCS2015_ModernCpp

frozenport 11y ago
One thing broken with moc is parralel build in MSVC. I think we all agree that moc is a dirty hack and needs to go.
- slavik81 11y ago
  I'd blame vcbuild/msbuild for its oddly limited parallel build rules. If you feel like switching build tools, I've personally used cmake, bjam, waf and qmake /w makefiles. All parallelize on both Windows and Linux. I'd recommend cmake or qmake /w makefiles, though qbs is worth looking into. We certainly don't all agree that the moc should go. An extra compiler adds complexity to the build, but the build is fast and the generated code is simple. That said, I'm interested to look into CS's alternative.
pjmlp 11y ago
So will Qt stop supporting commercial UNIX compilers and embedded platforms with compilers still stuck in C++98/03/partial 11?
- cjslep 11y ago
  Embedded system support is very much a high profile concern, and is definitely on Lars Knoll's radar. Given their enthusiasm, I would not start any doomsday rumors.
  - CountSessine 11y ago
    Another point to remember is that clang is changing the calculus of C/C++ compiler support in embedded. There are a lot of embedded systems (QNX comes to mind) that are switching to clang and getting very modern C/C++ support.
joe_the_user 11y ago
I recall that Qt 5.0 involved something of a turn toward Qml and maybe implied a gradual obsoleting of the entire old QWindow/QWidget hierarchy (not that this has happened but the "focus is on a new way of programming" according to the blogs of the time). So there's some logic in forking there. Qt 5 is web-fusion, integrated webkit everywhere and this for those oriented to plain old GUI windows forever. I still couldn't say whether this is a good idea.
jmgao 11y ago
> I'm also not sure why you would replace moc with template magic - moc will generally not fail (or will tell you if, say, you forgot to inherit from QObject), whereas template errors are midæval latin on a good day. Liberal usage of static_assert can make your life much less painful. For the specific case you mentioned, static_assert(std::is_base_of<QObject, T>::value, "Type does not inherit from QObject") gives you a reasonable error message (unfortunately, there's no way to stringify a template argument in the error message (yet?), but your compiler should show you where the class is being instantiated)

by cjslep 11y ago

frozenport 11y ago

One thing broken with moc is parralel build in MSVC. I think we all agree that moc is a dirty hack and needs to go.

slavik81 11y ago
I'd blame vcbuild/msbuild for its oddly limited parallel build rules. If you feel like switching build tools, I've personally used cmake, bjam, waf and qmake /w makefiles. All parallelize on both Windows and Linux. I'd recommend cmake or qmake /w makefiles, though qbs is worth looking into. We certainly don't all agree that the moc should go. An extra compiler adds complexity to the build, but the build is fast and the generated code is simple. That said, I'm interested to look into CS's alternative.

pjmlp 11y ago

So will Qt stop supporting commercial UNIX compilers and embedded platforms with compilers still stuck in C++98/03/partial 11?

cjslep 11y ago
Embedded system support is very much a high profile concern, and is definitely on Lars Knoll's radar. Given their enthusiasm, I would not start any doomsday rumors.
- CountSessine 11y ago
  Another point to remember is that clang is changing the calculus of C/C++ compiler support in embedded. There are a lot of embedded systems (QNX comes to mind) that are switching to clang and getting very modern C/C++ support.

joe_the_user 11y ago

I recall that Qt 5.0 involved something of a turn toward Qml and maybe implied a gradual obsoleting of the entire old QWindow/QWidget hierarchy (not that this has happened but the "focus is on a new way of programming" according to the blogs of the time). So there's some logic in forking there. Qt 5 is web-fusion, integrated webkit everywhere and this for those oriented to plain old GUI windows forever. I still couldn't say whether this is a good idea.

jmgao 11y ago

> I'm also not sure why you would replace moc with template magic - moc will generally not fail (or will tell you if, say, you forgot to inherit from QObject), whereas template errors are midæval latin on a good day. Liberal usage of static_assert can make your life much less painful. For the specific case you mentioned, static_assert(std::is_base_of<QObject, T>::value, "Type does not inherit from QObject") gives you a reasonable error message (unfortunately, there's no way to stringify a template argument in the error message (yet?), but your compiler should show you where the class is being instantiated)