Op 20/01/2016 om 15:48 schreef Ziller Eike:
On Jan 20, 2016, at 3:12 PM, Marc Mutz <marc.m...@kdab.com> wrote:
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.
+1
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 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).
I find it much nicer and more readable if I can just write sort(v).
Or "const List foos = transformed(myThings, &Thing::foo);"
instead of "List foos; std::transform(myThings.begin(), myThings.end(),
std::back_inserter(foos), std::mem_fn(&Thing::foo));”
(notice that “foos” is also not const in the “pure" std version)
We started some experiments with convenience wrappers for std algorithms for
use in Qt Creator when we started requiring C++11:
http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/libs/utils/algorithm.h
Nice, thanks for the link.
At a previous job, I ended up defining a macro called all (and a
constAll) that just expanded to begin(v), end(v). That already helped in
how verbose the calls to algorithms looked.
std::sort(all(v))
vs
std::sort(begin(v), end(v));
Sure, a macro is ugly, but it did the trick. When you need more control,
you can specify begin and end explicitly, of course.
But Qt is available in D and Python, too, so ...
why do they use C++ if they so hate it?
Maybe they don’t hate it, but still wished it had a less verbose API if you
don’t need the verbosity.
Indeed. After watching some courses by Stephanov, I actually learned to
appreciate it. But I stil dislike the API in many places. C++11 makes
much of the std easier to digest though.
André
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
