Hi Daniel, On Thu, Feb 19, 2015 at 01:29:48PM +0100, Daniel Teske wrote: > Hi, > > Standard C++ is evolving in a unprecedented pace at the moment. Both C++11 > and > C++14 added a lot of new good features. C++17 is planned to be a big step > again. > > Qt needs to evolve together with C++ or it will be a outdated toolkit stuck > in > a C++98 world.
Agreed, but there is no free lunch. See below. > > As an example, Qt's container classes and C++11 range based for loop do not > mix very well.[1] And for the same reason, the upcoming Ranges TS will not be > too useful for Qt's container. > > We have started using some parts of C++11 in Creator a year ago and our > experience is that lambdas (and std::function) are useful everywhere. Today > we > have more than 400 lambdas in Creator's source and have several interfaces > that take a std::function. > > I would expect that allowing C++11 in Qt would similarly lead to a wider > understanding on how to leverage the new features for better code and better > APIs. > > We need to start now and deprecate old compilers that do not support any > C++11 > features at all. I I suggest requiring support for lambda as > supported by MSVC 2010, g++ 4.5 and clang 3.1 in Qt 5.7 and deprecating all > platforms that do not in Qt 5.6. That would mean you would also deprecate QNX 6.5.0, 6.6.0 (which is a relatively new release), and BlackBerries. I personally would have loved to remove support for 6.5.0, since it is based on an old gcc version that can barely keep up with latest C++ developments (and keep giving me maintenance headaches from time to time). But strategically (read, comercially) speaking, this is still not possible - QNX 6.5.0 is still widely deployed. The move to 6.6.0 is happening at a slow pace - probably much slower than the time it will take us to reach Qt 5.7. One of the many reasons for that is that many of those systems running QNX are homologated and changing/upgrading involves lots of different process apart from the technical stuff. While I am not for keeping Qt stuck in the last century, I think a more sensible move would be to actually analyze how far we can push it given the current major platforms Qt is being used on, in other words, follow the market, and also take into account the trade-off of dropping platforms that generate revenue in the form of trainings, services, commercial licensing and last but not least, code contributions. I am taking QNX as an example because this is the platform I am familiar with, but I guess this could also affect other platforms such as Windows CE. Just my opinion. Thanks, Rafael -- Rafael Roquetto | [email protected] | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
