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

[Smith Martin]

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

When you use tools as you say you did, to find some knowledge we didn't know before, that's what discover means. But now you are changing the meaning again. When you started this discussion, I understood you to mean that QString, et al, are inefficient in the sense that there is a better way, and the QStringView is that better way. But now...

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

I understood your last reply to me to mean that we should be using QStringRef in more places anyway, whether we add QStringView to the mix or not, and that one thing that is clearly missing from Qt documentation is a "How and when to use" discussion for all of QString, QLatin1String, QString, QStringRef, QChar, const char*, and QByteArray, including which combinations of these classes to use and which combinations to avoid.

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

Both classes are documented, so we have no reason to think we don't understand them. You can argue that the doc team should be using Qt in anger as we go, and we should be discovering ourselves how Qt classes should be used to achieve optimal efficiency, but we don't have much time for that, given all the documentation that has to be written, so we depend on the engineers who design and/or use Qt classes to tell us when we need to add this higher level how-to knowledge. 

>I try to shake thing up here and
>there, because I'm a C++ fanboy and want Qt to stay relevant.

We all want that. That's why we have begun to improve the docs, at your recommendation, with regard to using QVector over QList. This QString/QStringView discussion is a similar situation, but with each reply from you, I become more confused about what problem you are trying to solve with QStringView. You listed most of the Qt string handling classes above. I think you are stating or implying that it is a mistake for a user to arbitrarily mix them in an application. But this is easy to do. qdoc uses QString everywhere. It is after all a string manipulation program.  We have recently improved qdoc performance by quite a lot, both by changing its strategy and by improving its use of string classes. I am sure there is more to be done, because qdoc mixes all the Qt string classes. That's easy to do because in a routine that is exclusively QString based, you find you need to call a function that returns a QByteArray or that only accepts a parameter that is const char*. 

Is QStringView meant to avoid this by adding APIs to Qt classes that use QStringView? Is the goal to include a QStringView API everywhere and then always pass around QStringViews instead of combinations of the string handling classes?

martin

________________________________________
From: development-bounces+martin.smith=theqtcompany.com at qt-project.org <development-bounces+martin.smith=theqtcompany.com at qt-project.org> on behalf of Marc Mutz <marc.mutz at kdab.com>
Sent: Saturday, October 17, 2015 10:13 PM
To: development at qt-project.org
Subject: Re: [Development] RFC: Proposal for a semi-radical change in Qt        APIs taking strings

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
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development