[Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Björn Breitmeyer]

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.breitmeyer at 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 at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5920 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150219/86514a61/attachment.bin>