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

[Bubke Marco]

On October 17, 2015 21:05:29 Marc Mutz <marc.mutz at kdab.com> wrote:

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

Yes but you cannot change everything in one day. You are referencing to something like http://www.gotw.ca/publications/optimizations.htm? I still believe sharing mutable data between threads is not a good idea. In most cases you start to sterilize your threads. Working on the same cache line is not an good idea. I think coping or slicing data between different threads is much smarter. In that sense functional programming is much easier to program as you write your own loop. So I am not sure that our current CoW story is the answer. Not because it is inefficient but because it can lead to inefficient systems because it makes sharing so easy.

But before we add new concepts we should agree in which direction we want to go. I have the feeling that we build an airplan but some want a jumbo jet, some a jet fighter and some, lets describe it so,  they want to fly to the moon because earth will maybe burning down and build something completely different which doesn't looks like an airplane anymore which we built over many years. I don't think we will be succed before we find a common context. So it would be good to describe what is our story. 

>> 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
Sent from cellphone