On Friday, 1 December 2017 11:57:33 PST Marc Mutz wrote: > > 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).
I understand it isn't. But can't QStringView be constructed from any StringLike? What overhead do you get with the solution above that you wouldn't by calling qCompareString directly? > > 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. Most of it, it has to. The standard library is written in C++. The only exceptions should be chapter 21 "Language support 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. Except that it's not efficient. In fact, it *used* to be efficient in libc++ for char (strlen) and wchar_t (wcslen), but ceased to be because of the C++17 requirement for constexpr. I'm not accepting a performance regression. > >> 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. I have picked my battles. As I said above, it used to be efficient in libc++ (using wcslen) then was made not to be so. See libcxx commit 291741 "Implement P0426: Constexpr for std::char_traits". Fortunately, I now see the LLVM developers applied the same hacky solution for libc++ that GCC devs did for libstdc++ to get performance back again. Also note in both cases this applies only to char and wchar_t. char16_t is not fixed. > > 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. I wouldn't mind co-authoring a paper about this. But we cannot wait for C++20 for it to be accepted for performance to pick back up. > <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). There's nothing wrong with std::mutex's definition. It can be made as efficient as QMutex, more than what QMutex is today and closer to what I have made it for Qt 6. It's just QoI: the libc++ and libstdc++ implementation operate on top of a pthread_mutex_t. If they ditch that, like we did, they can get the performance. It's an ABI-breaking change, though, because of std::mutex::native_handle_type. > 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. The corollary of what you're saying is that we need to continue innovating. That's what I believe I'm doing. And, again, where I think the committee got it wrong, I will NOT follow suit. Ditto for implementations, see QRandomGenerator. > 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. You and I disagree. > 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> -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development