[Development] QtCS 2017 QtCore sessions

[Marc Mutz]

On 2017-12-01 23:12, Philippe wrote:
>>> it's existential for Qt to get off its own container classes.
>>> I shall in the future extend that statement to anything that overlaps
>>> with std.
> 
> Two points to keep in mind:
> 
> 1) the std implementation varies with compiler vendors, each one with a
> different set of bugs, unit tests and sometimes performance. While with
> Qt, the implementation is more uniform. This to say, I feel more secure
> using Qt implementations for an application that runs on multiple
> platforms. And cross-platform is the core business of Qt...

You make it sound as if std implementations are much more buggy than 
Qt's. I don't even know how to respond. I'm sure STL, Marshal Clow, 
Howard Hinnant, and all the others std library implementers will be 
pleased with your analysis.

Have you tried using QVector with a type that has no default 
constructor? Using that nice API forces users to supply an unnatural 
operation on their types (if they control the types in the first place).

As I said multiple times before: my arguments would be pretty weak if 
Qt's implementation quality matched or exceeded the quality of the 
corresponding feature in the standard library (and that's why we have 
QStringView, incomplete as it still is, because of QString), but except 
for QString, and QFuture, which, however, lacks the QPromise 
counterpart, I don't see any other cases.

> 2) a majority of Qt users are not C++ wizards, and ease of use /
> intuitive api, is of primary importance... std does not always shine
> here.

If that analyis were true, you'd need to explain why it is, then, that 
the Qt containers now have more or less the same API as std ones, when 
in Qt 1 they were very different. And why I keep needing to fight off 
QOptional. These are ideas that do not come from Qt. They come from 
C++/Boost. Qt is "stealing" them, wrapping them up in a camelCase 
interface, omitting the hard parts of the implementation, adding some 
optimisation for Qt types, and then stand here as Thiago does and say 
that the Qt type needs to stay because of that optimisation. Even 
new-style Qt 5 signal/slot connections were available in this form in 
Boost since at least 1.32, ie. something like 2004. In Qt 3 times, 
people would have protected loudly over the need to write ugly code like 
&QLineEdit::returnPressed instead of SIGNAL(returnPressed()), but lo and 
behold, there's been no public outcry. Qt silently adopted the interface 
that was inspired by it's own invention, but had since succeeded in 
keeping up with the rest of the world (Boost.Signals). That's a _good_ 
change. It helps people integrate their code with Qt. because integrate 
they must.

Where I come from, we see customer's code "out there", and they almost 
never use Qt in isolation. They have to interface with some 2rd-party 
library which, naturally, does _not_ use Qt types, but std ones, and 
developers on those projects need to interact with both. They also 
surprisingly often know about and use Boost. Not only do they need to 
learn two different APIs (append() vs. push_back()), they also face the 
impedance mismatch between Qt and every other C++ library on the planet.

Developers just can't cocoon inside the Qt world. They need to interact 
with the real world, and Qt actively prevents that with its copies of 
upstream APIs all over the place, and it's antiquated (read: pre-C++11) 
programming model.

Two things have happened since 2010: C++ is progressing fast again, as a 
language, and, more importantly, the _tooling_ situation has 
dramatically improved. In a world where your static analysis tools 
actively warn you about common Qt idioms (mutexes, but also naked new 
all over the place, in violation of CoreGuidelines), Qt's insistence on 
providing it's own copies of std functionality force users to choose 
between Qt-ish APIs or static analysis coverage. A developer that 
chooses a nicer API if there's another cross-platform alternative which 
is functionally at least on par, but better integrated with his tools 
(IDE, compiler, clang-tidy, ...) should have a long meeting with his 
manager.

But Qt is just maintaining it's own NIH/our-APIs-are-superior stance. As 
evidenced by this thread. But it's users will move on. Personally, I'm 
doing more Modern C++ trainings than Qt trainings these days. That has 
to do with me not knowing QML much, but _also_ with a surge of interest 
in C++.

And, c'mon, std::optional's API is just not going to be topped by 
QOptional. What should they do? snake_case vs. camelCase? That's what we 
need to invest several man-days of development work in, to rename the 
functions and stick a Q in front of the class name?

Thanks,
Marc