[Development] QtCS 2017 QtCore sessions

[Philippe]

>>And, c'mon, std::optional's API is just not going to be topped by QOptional.

I don't know the QOptional plans (or no-plan), but as today, on the Mac,
the latest XCode 9.1 still does not provide std::optional.

With Qt, at least, when something is available, it is available in all
platforms, and Qt users can count on that.

>>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.

I also see that, except that boost dependency is often rejected.
But I also hear praises about Qt documentation and ease of learning.

I like your expression "impedance mismatch", but don't see this as a
problem in practise.
I mean, when a std:: container needs to be used for an interface with
another library, then let's use is. No big deal.

Philippe

On Sat, 02 Dec 2017 17:48:19 +0100
Marc Mutz <marc.mutz at kdab.com> wrote:

> 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