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

[André Somers]

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/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é