Den 20-01-2016 kl. 15:12 skrev Marc Mutz:
On Wednesday 20 January 2016 11:48:20 Bubke Marco wrote:
I think it would be productive for the discussion to build story of what we
want to do. A story of the big picture. Maybe as a first step we can show
how we tackle problems with Qt 5 and what are the proposed technologies in
the future C++ standard.
For me, Qt always was "the C++ standard library that C++ lacked". Ever since
Qt 3, it also integrated pretty well with the rest of the standard library.
That was easy, because pretty much the only thing that the standard library
had and Qt didn't were the algorithms, and Qt and the STL algorithms
integrated well. And there were conversion functions for pretty much
everything to/from std.
We even deprecated our algorithms when we started requiring full C++98 support
in 5.0.
We used to roll our own atomics, but dropped them in 5.7 when we required
partial C++11 support. We rolled our own foreach, and now it looks like we're
dropping it in favour of range-for.
I would like that trend to continue. The likely next candidates are threads,
futures and locks.
It sounds like everyone completely agrees on this. But that doesn't mean
it has to happen for every single class that might be implemented in STL.
Now that C++ punches out a new standard every three years, I would change that
into "Qt is the part of the C++ standard library that C++ sill lacks". I would
like Qt to continue to integrate well with the standard library and phase out
its own solutions as the standard library catches up.
We have been doing that in the past. It's just as C++ standardisation
accelerates, so will the need to phase out Qt features that got superseded.
I agree with this, but there might be problems with the release cycle of
Qt here. It's impossible to keep backwards compatibility while we switch
to new C++ versions. So either the Qt major releases will start
happening more often, or there are features that will just have to wait.
Thiagos list of things he has already implemented for Qt 6 is a good
example of this.
I perceive, however, that for many people, Qt is what makes them forget
they're working on C++, a language they would not otherwise poke at with a
long stick. They probably also cannot tolerate writing std::sort(v.begin(),
v.end()) instead of qSort(v). But Qt is available in D and Python, too, so ...
why do they use C++ if they so hate it?
Why do you think people hate C++? I love C++ but I hate the string
classes. I like some part of the std containers, I don't like their API.
In the same category of argument, I love Qt, but I hate that we don't
use exceptions.
Bo Thorsen,
Director, Viking Software.
--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
