I agree that it would be nice to have this, but we can do quite a bit of things with the Qt abstraction of most new features. And for std::function you can add new interfaces for compilers that do support it without breaking old code, its done for move constructors and co already.
Sure it would be nice to have all the nice new and nifty features, but then again even msvc 2010 only supports a subset of c++11 and msvc2013 still doesn't fully support c++11 or c++98, neither will old gccs. What is allowed what not. And then breaking in a minor version is not very customer friendly. Dropping this would for e.g. drop the support for WinCE. Of course we are also porting to WEC2013 and maybe Qt6 only supports WEC2013, whichs compiler supports most c++11 and a lot of the windows platform plugin code, but i agree with Andre that this is something for a major release. Right the support for old hardware/software stacks is a big plus for Qt. Thats because customers are sitting on those platforms and want to go into the future, but they can just do that when their old platform goes End of Life. So Qt offers them a way to already build the next generation software on their old stack and then switch over. This is a big selling point for Qt. Customers in aviation, medical, automotive and others have demands to support their products for 10-20 years. And they also have to certify their stack. So long point short, i would like to dicuss this for a move to Qt6 because of this and the points Andre mentioned already. -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions Am Donnerstag, 19. Februar 2015, 14:26:34 schrieb André Somers: > Daniel Teske schreef op 19-2-2015 om 13:29: > > 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. > > > > 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. > > > > daniel > > > > [1] ranged based for uses std::begin(container), which if not overloaded > > calls container.begin(), which detaches. > > > > So using range-based can be used: > > - If the container is const or > > - If the container is unshared or > > - To actually change the container's contents > > I do get what you mean, and I think they are all valid concerns. But I > am wondering if the move to support/base Qt API more on top of modern > C++ developments is not something that belongs in a major release > instead of a minor one. I think there are quite a few APIs in Qt that > may need reconsidering in this light. Would it not make more sense to > introduce a break like that in a major release instead? > > Perhaps Qt 6 should not be in the too far future, and might be focused > on breaking with the pre-C++ 11 heritage? At the same time, Qt 5 might > be kept alive next to that for a while yet. Not just with bugfixes, but > with whatever features are still feasible to backport to it. > > Question would be: if C++11 support could be dropped, what APIs would > benefit from being re-designed? > > André > > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development