[Development] QtCS 2017 QtCore sessions

[Philippe]

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

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.

Philippe

On Fri, 01 Dec 2017 20:57:33 +0100
Marc Mutz <marc.mutz at kdab.com> wrote:

> On 2017-12-01 19:26, Thiago Macieira wrote:
> > On Friday, 1 December 2017 01:31:18 PST Marc Mutz wrote:
> >> > Once those operator<=> are there, what benefit is there in having the
> >> > API
> >> > public and documented?
> >>
> >> The spaceship operator solves the problem for qCompareStrings(). One
> >> could say we already have all relational operators for all
> >> combinations
> >> of string-like objects to solve it for the user _now_, but
> >> qCompareStrings(), like operator<=>() return the full information,
> >> while
> >> relational operators only return a subset. You know that, I know. I'm
> >> just mentioning it for completeness sake.
> >
> > Ok, so your case is when you have two string-like objects and you want
> > to get
> > the ordering result. Since we don't yet have the spaceship operator,
> > you have
> > to call the compare() function. But you can't do that in clean, generic
> > code
> > because you don't know if the first argument is an actual QString or
> > QStringView, or if it's just a char16_t literal.
> >
> > Is that it?
> >
> > Why can't they write
> >
> > 	QStringView(s1).compare(s2) ?
> 
> I think you owe me a bit more thought on an answer to a mail of mine that that :P
> A quick look at the qCompareString() overload set will answer this question (hint: the lhs is not always QStringView).
> 
> >> Ah, but you said that the flaw was in the _standard_. But what you
> >> show
> >> are sub-optimal compiler implementations. There's nothing in the
> >> standard that prevents a compiler to implement char_traits::length()
> >> as
> >> a compiler intrinsic that can have different backends for constexpr
> >> and
> >> runtime evaluation.
> >
> > The flaw is in the standard because it does not allow me to implement
> > an
> > optimised version using whichever tools I want to.
> 
> The standard is not obliged to publicly give you all the plumbing to re-implement the standard library. The lack of plumbing is _sometimes_ a flaw in the standard, yes (std::invoke), but not always. You are supposed to use the standard library functionality, not re-implement it. In this case, the interface is char_traits::length, it exists on all supported platforms and does what we'd like it to do, incl., from C++17 on, constexpr.
> 
> >> So, would the following be acceptable:
> >>
> >> 1. QSV uses char_traits<char16_t>::length() to calculate the length
> >> (that was my initial implementation, but it's constexpr only starting
> >> with C++17). Then QSV(Char*) is only constexpr in C++17. I can live
> >> with
> >> that.
> >
> > No, because...
> >
> >> 2. You/Intel work on the compiler vendors to get
> >> char_traits<char16_t>::length() implemented as an intrinsic, with SIMD
> >> at runtime and compiler magic at compile-time?
> >
> > We should do that anyway, but depending on it means we'll have
> > performance in
> > 2021 or later (just look at how we have to build Linux binaries with
> > GCC 4.8).
> 
> Since char_traits::length would be called from inline code in QSV, its performance does not depend on how Qt was compiled, but on what the user's compiler is capable of. Also, presumably, the compiler was already optimizing char_traits::length() back when it wasn't constexpr (in C++11+14) and now has to implement something to not regress on runtime performance while still meeting constexpr restrictions. If it doesn't, then it's not our problem. It's SEP. And that is good. Pick your battles.
> 
> > The flaw exists today. My choice for fixing it is to sacrifice the part
> > we
> > don't really need: the constexprness.
> 
> Fixing it in Qt is limiting both Qt and the standard library. Don't do that.
> 
> <rant>
> The same is true, btw, of QMutex. Qt takes pride in how QMutex is faster than std::mutex. I think it's a shame. It shows that you didn't go the next step and get std::mutex fixed. Having QMutex not use std::mutex means that tsan doesn't work correctly, for one. Here, too, the "easy" local "fix" is to the detriment of both the standard library (slower-than-necessary mutex operations) and Qt (failure to work with tsan).
> 
> This habit of cocooning might have worked out ok when Qt was years ahead of the C++ standard library. But since those times in the 2000s, C++ has overtaken Qt in all aspects the committee decided to take on. Qt will have to adapt to this new reality or degrade to insignificance. Ride the wave or drown.
> 
> As I said elsewhere: innovate, don't replicate. See the bigger picture here: Where are the patches that integrate Qt's event system and signal/slots mechanism with Coroutines, to name just one? Instead you celebrate the perceived failures of the standard and Qt's ability to "fix" them by writing a SIMD strlen or take the null state of a Qt value class to optimize QOptional size.
> 
> This pattern repeats and repeats. V8 fork, anyone? When will Qt _finally_ learn? :) I said in my talks about QStringView that 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.
> 
> I explicitly do not exclude QString here, even though it's exempt for the time being. But people _do_ talk about a std::text_view, and it _will_ support utf8 strings and that, in combination, _will_ degrade QString to insignificance.
> 
> When Coroutines and ASIO land in C++, C++ will magically gain a cross-platform event loop. And more likely than not, you will have to integrate with it using Coroutines, futures and other awaitables, not the classic way of QAbstractEventDispatcher. It does not take a leap of imagination to assume that Coroutines TS will spark a ton of reactive GUI libraries for C++, incl. cross-platform ones. Qt needs to be prepared for that day. And the only way to prepare is to start working on innovative stuff and work with its various upstreams more, incl. the standard committee, and innovate. Stop. Fixing. Stuff. Locally. Get. Involved. Don't. Kodak. Qt.
> </rant>
> 
> >> Then we fix the problem where it should be fixed, and just piggy-back
> >> on
> >> the more general solution. And it's easy to sell to QSV users why that
> >> ctor is not constexpr until C++17 (and we don't even need any
> >> #ifdefery
> >> in the implementation).
> >>
> >> What do you think?
> >
> > We should fix the standard and we should help fix the implementations.
> > But I'm
> > not accepting a performance drawback for 3 or more years until then.
> 
> Pick your battles. I offered a compromise. I think it's a good one. And I think you're seriously overestimating the effect of your change. Not because it doesn't give a large performance boost, when exercised (I'm sure it does), but simply due to the fact that that code will be exercised very rarely. And, when actually exercised, the smaller i-cache footprint of "my" function might just beat "your" high-performance function in wall-clock time. Yes, in a library, every missed optimisation is some user's performance bottleneck. But we have an easy solution for that: people should be able to find in the ctor's documentation the recommendation to use qustrlen() manually.
> 
> Thanks,
> Marc
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development