[Development] What kind of airplane we want to build?

[Marc Mutz]

On Wednesday 20 January 2016 16:03:17 André Somers wrote:
> Op 20/01/2016 om 15:48 schreef Ziller Eike:
> >> On Jan 20, 2016, at 3:12 PM, Marc Mutz <marc.mutz at 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/alg
> > orithm.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.

Then now is the time to chime in on the C++ ranges proposal and voice your 
opinion(s).

"Let him speak now or forever hold his peace" :)

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts