[Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Marc Mutz]

On Saturday 17 October 2015 15:51:35 Smith Martin wrote:
> >Please understand my POV: I am of the firm belief that Qt has no business
> >creating inefficiencies for its users by sloppy implementation. Anywhere.
> 
> I think you are overreacting here, way too much. You have discovered a more
> efficient way to handle strings, but that doesn't mean Trolltech created
> inefficiency by a sloppy implementation of QString. QString has been used
> productively by many users for a long time. The fact that a moere
> efficient implementation exists doesn't mean the current implementation is
> inefficient.

I have not discovered anything. I merely use the existing tools and found that 
APIs outside the core Qt string classes largely ignore them, and probably 
rightfully so, since there's a combinatorical explosion when you combine 
QLatin1String, QString, QStringRef, QChar, const char*, QByteArray, etc.

QStringView is not more efficient than any of those. It is an abstraction over 
them, so that you can use, say, QStringRef in more places.

> >And please don't forget that QString fanboys can continue to massacre the
> >heap if they so wish. After all, we've had QStringRef for a long time
> >now, but most people still write str.mid(n).toInt() instead of
> >str.midRef().toInt().
> 
> But that is because we don't explain in the documentation the most
> efficient ways to use these classes together. And the reason it isn't in
> the documentation is we who write the documentation don't know what you
> know.

Then documenters should ask. There's a class QStringRef. If you/they don't 
understand what the difference is to QString and why it exists, just ask.

> >I find it intolerable that todays software
> >takes 1000x the memory, 1000x the CPU capacity and doesn't get a given
> >jobs done in less wallclock time than software 20 years ago.
> 
> But the fact is, it usually IS tolerable, because the applications you are
> talking about mostly work in human time.

Again, if it _were_ tolerable, we would all be using Java by now.

> Your efforts to improve Qt are most appreciated, but you make it sound like
> we should publicly name and shame all the engineers who ever worked on
> QString but who failed to find the holy grail of the most efficient
> implementation.

Erm, no, that's not what I'm saying. I'm said we shouldn't use sloppy 
implementation because people here claimed it was ok until proven otherwise. I 
merely pointed out (with many words) that that is not how C++ libraries are 
supposed to work. You can profile an application and you can profile a function. 
You cannot profile a library.

What TT created is magnificient. It greatly eased my learning of C++. But it 
needs to evolve to stay relevant, because hardware doesn't stay the same.

In the 2000s C++ was seen as a dying language by many. It is understandable 
that TT picked concepts from Java, the then-favourite language. But now C++ 
developers have gained back their self-esteem, because the industry has 
realised that they absolutely _need_ the efficiency of C++. Java doesn't cut it. 
We no longer look up to Java and C#.

When Qt was created, and for a long time afterwards, CoW was a good 
optimisation. When multithreading came along, it ceased to be. That is now 
universally understood, except in Qt where things are sometimes done because 
they have been done that way since Qt 1 or 2. I try to shake thing up here and 
there, because I'm a C++ fanboy and want Qt to stay relevant.

> I had no idea my heap was in such pain.

Play around with heaptrack. And watch Milian's talks at QtWS once they become 
available.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts